strtotime ??

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Paco de Wulp

Paco de Wulp

18/05/2015 23:30:19
Quote Anchor link
Omzetting gaat helemaal fout.

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
<?php
$tarief_datum_va
= '12-12-2099';
$tarief_datum_va = date('Y-m-d', strtotime($tarief_datum_va));
?>


En dit komt eruit:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
'1970-01-01'


Wat doe ik verkeerd ?
Gewijzigd op 18/05/2015 23:32:54 door Paco de Wulp
 
PHP hulp

PHP hulp

26/04/2024 01:49:36
 
Marthijn Buijs

Marthijn Buijs

18/05/2015 23:32:13
Quote Anchor link
Ik denk dat je datum invalid is.
 
Paco de Wulp

Paco de Wulp

18/05/2015 23:33:35
Quote Anchor link
12-12-2099 moet toch kunnen ?
 
Pipo Clown

Pipo Clown

18/05/2015 23:36:13
Quote Anchor link
Wat gebeurd er wanneer je 2099-12-12 gebruikt ?
 
Paco de Wulp

Paco de Wulp

18/05/2015 23:41:27
Quote Anchor link
Ook weer:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
'1970-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
 
Frank Nietbelangrijk

Frank Nietbelangrijk

19/05/2015 00:06:17
Quote Anchor link
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...)
 
- SanThe -

- SanThe -

19/05/2015 00:09:41
Quote Anchor link
Volgens mij is 2099 nog niet mogelijk met de huidige tijdsindeling.
 
Paco de Wulp

Paco de Wulp

19/05/2015 00:18:17
Quote Anchor link
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 !
 
Frank Nietbelangrijk

Frank Nietbelangrijk

19/05/2015 00:24:17
Quote Anchor link
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:

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 :-)
 
Marthijn Buijs

Marthijn Buijs

19/05/2015 07:45:36
Quote Anchor link
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...)


Welke functies zouden er dan gebruikt moeten worden?
 
Frank Nietbelangrijk

Frank Nietbelangrijk

19/05/2015 09:53:13
Quote Anchor link
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.
 

19/05/2015 09:55:56
Quote Anchor link
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.
Gewijzigd op 19/05/2015 09:57:38 door
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.