strtotime ??
Omzetting gaat helemaal fout.
En dit komt eruit:
Wat doe ik verkeerd ?
Code (php)
En dit komt eruit:
Wat doe ik verkeerd ?
Gewijzigd op 18/05/2015 23:32:54 door Paco de Wulp
Ik denk dat je datum invalid is.
12-12-2099 moet toch kunnen ?
Wat gebeurd er wanneer je 2099-12-12 gebruikt ?
Ook weer:
Toevoeging op 18/05/2015 23:45:54:
01-01-2015 gaat wel goed --> 2015-01-01 !?
Toevoeging op 18/05/2015 23:45:54:
01-01-2015 gaat wel goed --> 2015-01-01 !?
Gewijzigd op 18/05/2015 23:57:07 door Paco de Wulp
Helaas maar op 19 januari 2038 zullen de 32 bits van de unix timestamp vol zitten. Dat is best al snel en daarom vindt ik het nu al raadzaam om deze functies te vermijden.
(aan de andere kant is een website na 10 jaar al zo hopeloos verouderd...)
(aan de andere kant is een website na 10 jaar al zo hopeloos verouderd...)
Volgens mij is 2099 nog niet mogelijk met de huidige tijdsindeling.
Inderdaad @Frank tot 18 januari 2038 gaat het goed, erboven al niet meer. Nou dan kunnen mijn gebruikers geen datum invullen hoger dan 18 januari 2038. Probleem opgelost !
2038 - 1970 = 68 jaar
68 x 365,25 dagen = 24837 dagen
24837 x 24 uur = 596088 uur
596088 x 60 minuten = 35.765.280
35.765.280 x 60 seconden = 2.145.916.800 seconden.
maximale waarde van een 32 bit integer: 2^32 = 2.147.483.647
2.145.916.800 - 2.147.483.647 = 1.566.847 seconden die nog overblijven op 01-01-2038. Het klopt vrij aardig al is mijn berekening niet nauwkeurig ivm met schrikkeljaren.
Toevoeging op 19/05/2015 00:26:13:
Voorlopig wel Paco :-)
68 x 365,25 dagen = 24837 dagen
24837 x 24 uur = 596088 uur
596088 x 60 minuten = 35.765.280
35.765.280 x 60 seconden = 2.145.916.800 seconden.
maximale waarde van een 32 bit integer: 2^32 = 2.147.483.647
2.145.916.800 - 2.147.483.647 = 1.566.847 seconden die nog overblijven op 01-01-2038. Het klopt vrij aardig al is mijn berekening niet nauwkeurig ivm met schrikkeljaren.
Toevoeging op 19/05/2015 00:26:13:
Paco de Wulp op 19/05/2015 00:18:17:
Inderdaad @Frank tot 18 januari 2038 gaat het goed, erboven al niet meer. Nou dan kunnen mijn gebruikers geen datum invullen hoger dan 18 januari 2038. Probleem opgelost !
Voorlopig wel Paco :-)
Frank Nietbelangrijk op 19/05/2015 00:06:17:
Helaas maar op 19 januari 2038 zullen de 32 bits van de unix timestamp vol zitten. Dat is best al snel en daarom vindt ik het nu al raadzaam om deze functies te vermijden.
(aan de andere kant is een website na 10 jaar al zo hopeloos verouderd...)
(aan de andere kant is een website na 10 jaar al zo hopeloos verouderd...)
Welke functies zouden er dan gebruikt moeten worden?
Al hoewel het op een 64 bits machine zo op te lossen is, heeft php hier zover ik weet nog geen gebruik van gemaakt. De mysql datetime heeft op dit moment het grootste bereik.
https://dev.mysql.com/doc/refman/5.5/en/datetime.html
dit betekent als je hiervan gebruik wilt maken dat je binnen php niet meer met datums rekent maar hiervoor sql quiries gebruikt. .
Tenzij iemand een beter idee heeft natuurlijk.
https://dev.mysql.com/doc/refman/5.5/en/datetime.html
dit betekent als je hiervan gebruik wilt maken dat je binnen php niet meer met datums rekent maar hiervoor sql quiries gebruikt. .
Tenzij iemand een beter idee heeft natuurlijk.
Op zich is er toch niets mis met strtotime, de context is UNIX timestamps. Timestamps zijn letterlijk tijdstempels. Een stempel gebruik je om dingen in het nu te markeren. Zoals de regels in een logbestand. Het concept van tijdstempels is van nature minder geschikt voor datumberekeningen, zeker als die (ver) in de toekomst liggen. Tegen de tijd dat het 2038 is zullen we hopelijk toch wel over minimaal een 64-bits versie van PHP beschikken, en dan is het 32-bits-probleem opgelost.
Pro memorie, hoe lang duurde het ook alweer voordat we van 16 bit af waren toen 32 bit geïntroduceerd werd? Met de i80386 werd 32 bit werd gelanceerd in 1985, en toch waren er in Windows 95 nog de nodige 16 bit DLL-s te vinden. Dat is zeler zo'n 10 à 15 jaar. 64-bit-processoren kwamen ergens in 2003 beschikbaar. Voortbordurend op in het verleden behaalde resultaten zouden we ergens in 2020 verlost mogen zijn van de oude 32 bits spullen.
Of we die deadline halen hangt af van de beschikbare tijd van programmeurs, fouten in C-pointers opsporen als men gaat compileren met 64-bit kan tijdrovend zijn. En het hangt af van de prijs / gebruik van computergeheugen dat met het verdubbelen van het aantal bits ook ineens gehalveerd wordt voor programma's. Voor desktop PC's en servers niet zo erg natuurlijk, maar er komen steeds meer dedicated systeempjes in kader van het 'internet of things' en die zullen vaker worden opgeleverd met minder geheugen dan gewone computers.
Pro memorie, hoe lang duurde het ook alweer voordat we van 16 bit af waren toen 32 bit geïntroduceerd werd? Met de i80386 werd 32 bit werd gelanceerd in 1985, en toch waren er in Windows 95 nog de nodige 16 bit DLL-s te vinden. Dat is zeler zo'n 10 à 15 jaar. 64-bit-processoren kwamen ergens in 2003 beschikbaar. Voortbordurend op in het verleden behaalde resultaten zouden we ergens in 2020 verlost mogen zijn van de oude 32 bits spullen.
Of we die deadline halen hangt af van de beschikbare tijd van programmeurs, fouten in C-pointers opsporen als men gaat compileren met 64-bit kan tijdrovend zijn. En het hangt af van de prijs / gebruik van computergeheugen dat met het verdubbelen van het aantal bits ook ineens gehalveerd wordt voor programma's. Voor desktop PC's en servers niet zo erg natuurlijk, maar er komen steeds meer dedicated systeempjes in kader van het 'internet of things' en die zullen vaker worden opgeleverd met minder geheugen dan gewone computers.




