Uren niet meer laten afronden

Door Ray Mond op 18-08-2020 19:31 gewijzigd op 18-08-2020 19:35

2.152 views

Beste mensen,

We hebben een script (overgenomen) nu worden de aantal uren (werkzaamheden) ingevoerd in de database als starttijd bijvoorbeeld 01:15 tot 01:30, dit is prima opgenomen in de database maar op moment dat ik de uren dus opvraag staat het echter afgerond als 0 uur, pas op het moment dat ik van 01:00 tot 02:00 als voorbeeld zal doen dan zal het weergegeven worden als 1 uur.


$datum = date("d-m-Y",strtotime($start));
				$startTijd = date("H:i",strtotime($start));
				$eindTijd = date("H:i",strtotime($eind));

				$totaal = $eindTijd - $startTijd;

				//$totaal = $totaal / 60;
				$urenTotaal += $totaal;

En dan het stukje waar de uren worden opgeroepen:


<th colspan="4"><?=number_format($urenTotaal, 2, ',', '.')?> uur</th>

Hoe kan ik de uren dus ook als kwartier, halfuur en dergelijke laten tonen?

Willem vp

19-08-2020 19:44 gewijzigd op 19-08-2020 19:47

Thomas van den Heuvel op 19/08/2020 10:02:58

Herinner je nog de paniek met de millenniumbug? Ik ben er nog steeds van overtuigd dat dat verbleekt bij wat er ons in 2038 staat te wachten, ondanks het feit dat we dit met zijn allen mijlenver konden zien aankomen :).

Ik denk dat dat best mee zal vallen. Eigenlijk hoeft alleen maar de 32-bits integer te worden opgerekt naar 64-bits en dat is in de praktijk al op veel plaatsen gebeurd. Voor zover ik weet, gebruiken alle 64-bits besturingssystemen al 64-bits timestamps (en de laatste desktop-processor van Intel was de Pentium 4, die al 12 jaar niet meer wordt gemaakt, dus er is geen enkele reden om nog een 32-bits OS te gebruiken). Alleen in stong typed languages kun je natuurlijk niet zomaar een 32-bits integer oprekken naar 64 bits. En in binaire databestanden/datastromen kun je niet zomaar 4 bytes erbij bedenken, want dan stort alle verwerkingssoftware in. Dat zal zich uiteindelijk vanzelf wel oplossen, want al ver voor 2038 zal de behoefte bestaan om timestamps na 2038 te kunnen representeren (oh, wacht, dat hadden we met Y2K ook...)

Met het oprekken van timestamps naar 64 bits kunnen we in ieder geval weer een dikke 292 miljard jaar vooruit, en aangezien de aarde naar verwachting over 900 miljoen jaar te heet is geworden voor elke vorm van leven denk ik dat dat wel zal voldoen. Dat Y2K-probleem is wat dat betreft een beetje halfslachtig opgelost, want over een paar duizend jaar hebben we alweer het Y10K-probleem en in theorie zou de mensheid dan nog wel kunnen bestaan. ;-)

Toevallig had ik nog ergens in een hoekje de broncode van PHP 5.6.6 (uit 2015) liggen en daar wordt intern al een signed long long (64 bits dus) gebruikt voor integer timestamps. Ook Postgres ondersteunt het al sinds (als ik het me goed herinner) 2009. MySQL loopt was dat betreft nog wel achter; daar staat al sinds 2005 een bug/feature request open om de unix_timestamp() te vergroten.

Het network time protocol maakt overigens het helemaal bont: NTPv4 (uit 2010) gebruikt 128 bits voor een timestamp: 64 voor de secondes en 64 voor de fractionele secondes; daar kun je dus elk moment van de komende 290 miljard jaar tot in zeptosecondes nauwkeurig specificeren.

Thomas van den Heuvel

19-08-2020 20:04 gewijzigd op 19-08-2020 20:04

Voor software en hardware die met de tijd zijn meegegroeid zal dat waarschijnlijk niet zo'n punt zijn, de problemen zullen vooral in de hoek zitten met allerlei legacy-spul die vanwege (on)zinnige redenen niet vervangen of bijgewerkt is (of kan worden). Als er een ding is wat we geleerd hebben van onze historie... :)

Reageren

Inloggen om te reageren