We moeten ophouden om datums als ticks op te slaan. Men heeft dit vroeger bedacht omdat het geheugen ruimte bespaarde, maar dat is tegenwoordig niet meer relevant, zelfs niet op kleine apparaten.

Ik stel voor dat we gewoon een struct gebruiken met integers voor jaar / maand /dag, uren / minuten / seconden / milliseconden. Ongeveer zoals ISO 8601 dus.

Ik zie de volgende nadelen om over te gaan op een struct met integers:

- Wat gaat gelden als de universele tijd?
- Niet-westerse culturen maken niet altijd gebruik van de gregoriaanse kalender, maar werken bijv. met een maankalender of in Japan met verschillende era's gebaseerd op hoeveel jaar een keizer aan de macht is. Dan zou je dus allerlei conversies moeten gaan bepalen.
- Apparaten moeten dan "weten" hoe de jaartelling verloopt. M.a.w. apparaten moeten rekening gaan houden met schikkeljaren of continu in verbinding staan met het internet om te bepalen in welke "tijd" (jaar/maand/dag/uur/seconden/milliseconden) we leven

Er zullen er vast nog wel meer zijn. Ben benieuwd of iemand anders nog een nadeel weet.

Rekenkundige bewerkingen worden een ramp. Nu kun je bijvoorbeeld 2 timestamps van elkaar aftrekken en dan weet je hoelang een event geduurd heeft. Probeer dat maar eens met aparte variabelen voor jaar/maand/dag enz.

Schrikkeljaren, zomertijd/wintertijd, om de zoveel jaar eens extra seconde aan het eind van het jaar.

Het grote voordeel van een enkele teller met een vast gedefinieerd nulpunt is dat je de registratie scheid van de representatie. Zoals jij ook al aangaf, het eerste is iedereen het snel over eens, het tweede minder.

Nu kun je bijvoorbeeld 2 timestamps van elkaar aftrekken en dan weet je hoelang een event geduurd heeft

Helaas, die vlieger gaat niet helemaal op:

om de zoveel jaar eens extra seconde aan het eind van het jaar.

Schrikkelseconden zitten niet in de unix timestamp. Het tijdsstip 31-12-2016 23:59:60 GMT is bijvoorbeeld niet te representeren. 23:59:59 was 1483228799, maar 1483228800 is 1-1-2017 0:00:00 GMT.

[Reactie gewijzigd door .oisyn op 14 juli 2017 09:32]

Je bedoelt: Er zit een fout in de representatie die Unix in veel of misschien wel alle gevallen doet van de registratie.
Of het nou 23:59:59 of 23:59:60 was, die ene extra seconde is geregistreerd. Dat was namelijk 1483228800. Dat we het daarna een seconde fout zijn gaan weergeven ligt niet aan de int32, maar aan ons.

Nee, dat bedoel ik niet. Schrikkelsecondes zitten expliciet niet in de timestamp. Het is gedefinieerd dat er precies 86400 tikken in een dag zitten. Timestamp 1483228799 duurde in feite twee seconden*. Hoe daar vervolgens meestal mee wordt omgegaan is dat er voor een korte tijd een bewuste drift wordt geintroduceerd - de klok tikt iets langzamer totdat hij weer synchroon loopt met wat de timestamp hoort te zijn.

*Ah blijkbaar klopte dat ook niet helemaal. 1483228800 is gewoon een ambiguë tijd, hij representeert zowel de schrikkelseconde zelf als de nieuwjaarsseconde.

https://en.wikipedia.org/wiki/Unix_time#Leap_seconds

[Reactie gewijzigd door .oisyn op 14 juli 2017 10:07]

Dat is juist het scheiden van registratie en representatie waar locke het over heeft. Scrikkelsecondes zitten in de representatie.

Nee, hij heeft het erover dat de klok gewoon doortikt. Dat is dus niet zo. Alleen zat ik er naast bij welke timestamp de schrikkelseconde werd gerekend.

.edit: oh wacht je hebt het over locke, niet kakanox . Inderdaad.

[Reactie gewijzigd door .oisyn op 14 juli 2017 11:11]

En feitelijk hebben we daarmee dus een probleem in de representatie opgelost door te rommelen met de registratie.

Natuurkundig gezien best wel jammer. In feite zou je dan namelijk een computer kunnen laten berekenen dat je moleculen sneller transporteert dan het licht, door te zorgen dat ze getransporteerd worden in een moment waar die schrikkelseconde ook in zit.

[Reactie gewijzigd door kakanox op 14 juli 2017 12:48]

Dat is geen enkel probleem, je library most rekening houden met de representatie van lokale veranderingen zoals schrikelseconden en jaren die meestal verschillen van locatie tot locatie. Het is niet alsof tijd letterlijk een seconde of een dag stilhoudt, het is enkel om te zorgen dat je kalender niet verschuift.

Het punt was dat het verschil tussen twee unix timestamps niet letterlijk het aantal secondes tussen die twee events is. Je kan er dus een stuk of 27 seconde (als je vanaf de epoch rekent) naast zitten. Het is natuurlijk marginaal, maar het kán essentieel zijn.

En ja, uiteraard heb je gewoon libraries die het voor je oplossen. Maar de meeste programmeurs zullen geneigd zijn om twee timestamps gewoon af te trekken (en toegegeven, voor de meeste zaken is dat ook wel gewoon prima).

Gaat niet (goed) werken in microcontrollers... daar ben je vaak erg gelimiteerd in je opslag, dan wil je niet een complete struct op moeten slaan (inclusief de instructies schrijven om bewerkingen op uit te voeren).

Gelukkig gebruik je bij microcontrollers meestal een rtc om de tijd bij te houden .
Je kan dan veelal via spi of door geheugenadressen te lezen (ofzo) verschillende tijd/datum velden opvragen. Afaik bestaan die nu al met verschillende kalenders én met verschillende overflow datums.
Bovendien hoeven die rtc's helemaal geen unix timestamps te gebruiken, of zelfs een gemeenschappelijke 0 te gebruiken. Het is tenslotte maar in een paar use cases dat zo'n device universeel over tijd hoeft te 'praten'.

De problemen situeren zich eerder in computersystemen, juist omdat die al heel lang wijd verspreid zijn en net die timestamps gebruiken als universele standaard om tijd te communiceren over systemen heen. De interoperabiliteit valt of staat vaak met de juiste (interpratie van) tijd.

Klopt, maar als je nanoseconde precisie wil hebben gaat een RTC je daar ook niet bij helpen. Zeker niet als je een bus als SPI of I2C gaat gebruiken. Ik ben geen expert op gebied van microelectronics, dus wellicht dat ik er naast zit. Maar wanneer een RTC elke nanoseconde een update over de bus schreeuwt, kunnen andere devices op dezelfde bus toch niets meer 'zeggen'?

Dat valt dan weer op te lossen door de tijd te vragen wanneer je dit nodig hebt, in plaats van de RTC een update te laten sturen, maar dan kan je qua timing er weer naast gaan zitten lijkt me.

Euh ja, maar hoe vaak moet je met nanosecondes werken? Een rtc heeft meestal velden tot op de seconde.

Wat mij betreft is voor een RTC werken op de seconde ook genoeg. Ik zie nu dat ik een aantal reacties door elkaar begin te halen wat voor de verwarring zorgde ;-)

Nanoseconde precisie?
RTC's zijn om de tijd/dagen bij te houden.
Sommige microcontrollers hebben overigens een RTC ingebouwd, dat scheelt je een bus (vertraging en resources).

Maar de interne timers van de microcontrollers zijn dan weer heel geschikt voor kortere timings. En anders moet je een loopje van nop operaties gaan zetten tussen de instructies in.

Om als voorbeeld een Arduino te nemen met 16Mhz klok.
Nanosecondes: " a single cycle instruction takes 1 divided by 16MHz - which is 62.5 nanoseconds".
Voor een factor van 62.5 nanoseconden vertraging kun je dus een aantal NOP instructies op een rij zetten.
Speel eens met een timer calculator: http://eleccelerator.com/avr-timer-calculator/
16Mhz (16000000Hz), in 0.000001 seconden (1000 nanoseconden) zitten bijvoorbeeld 16 timer ticks.

Oftewel, je kan de snelheid van een kogel meten met een Arduino (of microcontroller) de timing is exact genoeg. Maar een RTC(C) wordt gebruikt voor tijd de juist langer duurt (en meerdere timer overflows en moeilijkheden zou opleveren), of het afhandelen van datums en behouden van tijd tijdens stroomverlies (ze hebben namelijk een backupbatterij).

Maar wanneer een RTC elke nanoseconde een update over de bus schreeuwt, kunnen andere devices op dezelfde bus toch niets meer 'zeggen'?

Klopt, dus het is een stuk handiger om niet elke nieuwe timestamp over de bus te gooien. Als dat ding gewoon zijn mond houdt totdat een ander component "wat is de huidige tijd?" op de bus zet en alleen dan antwoord geeft, spaart dat niet alleen een heleboel belasting op de bus, maar ook een flink stuk energieverbruik (je mond houden is zuiniger dan constant kletsen).

Niet altijd, RTC en batterijen dragen kosten. De Raspberry pi heeft geen RTC.

De rpi is een mini computer, niet echt een microcontroller.
Overigens kan je prima een rtc op de rpi hangen!

De kosten voor een RTC zijn minimaal, maar bij massaproductie is het zonde om een RTC er op te zetten als het niet direct nodig is.

- Wat gaat gelden als de universele tijd?

Alle computers in de wereld maken nu al gebruik van de integers als 'universele tijd'.
Wikipedia verwoord het heel mooi: "The Gregorian calendar is the de facto international standard, and is used almost everywhere in the world for civil purposes. It is a purely solar calendar[...]"
En "The Chinese, Hebrew, Hindu, and Julian calendars are widely used for religious and social purposes."
(p.s. verwar civil niet met civilized!)

- Niet-westerse culturen maken niet altijd gebruik van de gregoriaanse kalender, maar werken bijv. met een maankalender of in Japan met verschillende era's gebaseerd op hoeveel jaar een keizer aan de macht is.

Nope, er zijn géén elektrische systemen daar die de 'era' leidend maken. Er kan hier en daar wel ondersteuning voor zijn, maar het probleem is dat je niet van te voren weet elke 'era' er ktoekomst. Als de huidige keizer komt te overlijden en de volgende treed aan, dan is het een nieuwe 'era'. Je kan een apparaat geen toekomstvoorspelling laten doen
Quote van Java: "The Japanese Imperial calendar system is the same as the ISO calendar system apart from the era-based year numbering."

- Apparaten moeten dan "weten" hoe de jaartelling verloopt. M.a.w. apparaten moeten rekening gaan houden met schikkeljaren of continu in verbinding staan met het internet om te bepalen in welke "tijd" (jaar/maand/dag/uur/seconden/milliseconden) we leven

Wij gebruiken ons zonnestelsel om de kalender universeel en 'kloppend' te laten verlopen. Dit is de enige standaard die geen enkele persoon of enkel land kan veranderen.

We hebben ook atoomklokken, maar stel dat deze ooit falen omdat ze afwijken om wat voor (nu nog onbekende) reden dan ook? Een land kan dus hun atoomklok veranderen en roepen dat andere het fout hebben. En nu? (ja, dit is wel erg ver gezocht en alu-hoedje stijl haha)
Je heb dus een materiaal leidend gemaakt (net als onze kilo) maar dan kán grote verschillen opleveren naar mate de tijd vordert. Zie ook deze zeer informatieve video over de kilo.

Er zullen er vast nog wel meer zijn. Ben benieuwd of iemand anders nog een nadeel weet.

Het nadeel is dat iedereen alles opnieuw moet gaan herprogrammeren om een struct te snappen (of simpelweg meerdere vars, welke soort ze ook zijn).

Ik zie het nog eerder gebeuren dat we de gemakkelijke weg uit zoeken. Een backward compatible API oid. Een tweede 32-bit integer en een tussenliggende laag die alle call's afvangt om de integer uit te lezen en de twee nieuwe integers bij elkaar optelt ofzo. Fake the system dus

Gezien hoe gemakkelijk er nu met de IT wordt omgegaan is men er helaas zelfs met de waarschuwingen nu in 2038 echt niet klaar voor, mark my words.

Je hebt zeker weten gelijk. Ik denk dat het belangrijk is dat er een onderscheid gemaakt wordt tussen het opslaan van een tijdstip en het interpreteren daarvan. Opslaan als een interpretatie (bv. 13:32 uur op 3 juli 2017) is waarschijnlijk een slecht idee, omdat het lastig kan worden die om te zetten naar andere interpretaties. Epoch time is juist zo sterk omdat het "gewoon" secondes telt vanaf een bepaalde datum. Met een beetje rekenwerk is dat zo om te zetten naar begrijpelijke (menselijke) interpretatie in allerlei andere kalenders en systemen.

Al die nadelen gelden net zo goed voor het huidige systeem en alle andere denkbare alternatieven

rekenen met epoch time gaat lijkt me ook makkelijker: tijdstip1 - tijdstip2 ofzo

der zijn veel te veel uitzonderingen bij conversie, leap seconds, landen met 2 verschillende tijdzones, landen die een half uur extra nemen, landen die op een ander moment van winter-zomertijd veranderen, landen die opeens van UTC+x veranderen, landen die opeens een dag verspringen, landen die op elk jaar van 24 op 25 maart van jaar veranderen etc...
https://www.youtube.com/watch?v=-5wpm-gesOY

[Reactie gewijzigd door jeroen7s op 14 juli 2017 09:42]

We moeten ophouden om datums als ticks op te slaan.

Als wij het opslaan als 64 bit in plaats van 32 bit dan hebben wij tot het einde van het universum de tijd om het volgende probleem op te lossen. Het belangrijkste is dat alle systemen dit vanaf 2038 doen.

Nog 20 jaar de tijd. Dat is voldoende tijd om een voorstel te doen voor een 64 bit clock en voor het ontwikkelen van een runtime patch die 99,999% van alle legacy software correct laat werken met het nieuwe formaat. Daarna is het business as usual.

[Reactie gewijzigd door The Zep Man op 14 juli 2017 06:50]

Maar waarschijnlijk wachten we tot het laatste moment om het op te lossen, wel zo spannend Dat deden we tenslotte ook met het jaar-2000gebeuren. Dat werd in 1985 al aangekondigd in een nieuwsgroep. (2038 wordt ook in dat draadje genoemd). (het probleem werd zelfs door sommige mensen afgedaan met "tegen die tijd hebben we allang wat anders"

https://groups.google.com/forum/#!topic/net.bugs/ZGlqGwNaq3I

Code uit een progje wat ik in 1989 schreef:

if(byBadDate)
{
vWriteStat("*** WARNING - The date on your system appears to be out of range");
vWriteStat("*** This program stops functioning correctly if the date is set");
vWriteStat("*** earlier than Jan. 1, 1970 or later than Jan. 18, 2038");
vWriteStat(" ");
}

[Reactie gewijzigd door scsirob op 14 juli 2017 08:12]

Ware het niet dat de unix timestamp een signed integer is, en je dus prima data vanaf ongeveer 1902 kan representeren.

Dat kan, maar MS-DOS en mijn toenmalige C compiler kon er in ieder geval niet mee omgaan. Zelfs als de compiler het gekund had, dan nog had mijn programma destijds de mist in gegaan, dus de waarschuwing klopte wel degelijk

Niet alle versies van C en microcontrollers konden om met 32-bit signed integers, enkel unsigned. Net zoals nu, versies voor GCC 4.8 kunnen niet om met 128 bit signed integers.

kunnen we dan niet gewoon op januari 18 2038 de teller op nul zetten en die dag als start datum gebruiken ? Ofwel van de 32 bits, 1 bit gebruiken om het aantal cycli op te slaan.
Overgaan naar 64 bits kan dat geen probleem opleveren bij al de huidige 32bit systemen ?

Sowieso niet op 0.
Ik werk nog heel regelmatig met data 4,5, of 6 jaar geleden, en schep er ook wel gemak en plezier in dat ik m'n eerste digitale muziek in 2003 heb gekocht (timestamp staat ondanks verschillende servers nog steeds prima op de bestanden).

vandaar 1 bit gebruiken om te weten hoever je in het verleden moet gaan.

Dan krijg je iets zoals dit :
0 000.000.000 = Thursday 1 January 1970 00:00:00
1 000.000.000 = Saturday 1 January 2000 00:00:00 --> +30j
2 000.000.000 = Tuesday 1 January 2030 00:00:00 -->+30j (Huidige cyclus)
3 000.000.000 = 2060
4 000.000.000 = 2090
...
(30 jaar kan misschien meer zijn. Maar je moet wel 1 extra bit gebruiken voor de teller... Misschien niet ideaal. Maar toch korter dan een string)

Probleem is dat na 210 jaar hebben we weer hetzelfde probleem... Maar tegen die tijd zal niemand nog met 32 bit systemen werken hoop ik.

[Reactie gewijzigd door Boermansjo op 14 juli 2017 10:45]

kunnen we dan niet gewoon op januari 18 2038 de teller op nul zetten en die dag als start datum gebruiken ? Ofwel van de 32 bits, 1 bit gebruiken om het aantal cycli op te slaan.
Overgaan naar 64 bits kan dat geen probleem opleveren bij al de huidige 32bit systemen ?

vandaar 1 bit gebruiken om te weten hoever je in het verleden moet gaan.

Dan krijg je iets zoals dit :
0 000.000.000 = Thursday 1 January 1970 00:00:00
1 000.000.000 = Saturday 1 January 2000 00:00:00 --> +30j
2 000.000.000 = Tuesday 1 January 2030 00:00:00 -->+30j (Huidige cyclus)
3 000.000.000 = 2060
4 000.000.000 = 2090
...
(30 jaar kan misschien meer zijn. Maar je moet wel 1 extra bit gebruiken voor de teller... Misschien niet ideaal. Maar toch korter dan een string)

Probleem is dat na 210 jaar hebben we weer hetzelfde probleem... Maar tegen die tijd zal niemand nog met 32 bit systemen werken hoop ik.

Ik denk dat je bits en bytes verwart. Als je van de 32 beschikbare bits er één gebruikt om het aantal cycli te tellen heb je precies ruimte voor twee cycli (teller=0 / teller=1).

Huidige situatie:
32 bits beschikbaar waarvan één om aan te geven of het om een positief of negatief getal gaat. Dat zorgt voor 2^31=2147483648 verschillende timestamps. Er passen 86400 seconden in een dag en 365 1/4 dagen gemiddeld in een jaar -> ruim 68 jaar.

Jouw voorstel:
We gebruiken een extra bit om aan te geven in welke cyclus we zitten. Dan hebben we dus nog 30 bits over, dat zorgt voor 2^30=1073741824 verschillende timestamps. 86400 seconden in een dag en 365 1/4 dagen in een jaar -> 34 jaar per cyclus.

We hebben 2 cycli van 34 jaar, dat levert een totaal van ruim 68 jaar op.

Gefeliciteerd! Je hebt de timestamp opnieuw uitgevonden, maar nu ingewikkelder

Bij iedere verdubbeling van het aantal cycli halveer je de beschikbare tijd in zo'n cyclus.

(Yes, I know, we zouden kunnen overstappen op unsigned timestamps, dan komt er wél een extra bitje vrij, maar dan lijkt een 64bit int een stuk logischer)

Inderdaad wat in de mist gegaan met de berekening. Misschien gewoon dat dna storage technologie verder uitwerken en toepassen. (DNA digital data storage). Dan kunnen we voor een paar miljoen jaren verder met de +1 methode

Huidige situatie:
32 bits beschikbaar waarvan één om aan te geven of het om een positief of negatief getal gaat.

Ik denk dat je het moet lezen als:
"32 bits beschikbaar, zonder aan te geven of het om een positief of negatief getal gaat." Oftewel inderdaad unsigned timestamps.

De reden waarom je dit absoluut niet wil doen is omdat je dan de betekenis van bestaande (negatieve) timestamps verandert. Als je dan toch incompatible wordt, doe het dan alsjeblieft met een oplossing die nog een tijdje mee kan (lees: 64 bit (signed!) timestamps). Daarmee kunnen we elke seconde vastleggen van de Big Bang tot ver voorbij het bestaan van de laatste machine die op welke manier dan ook compatible is met 64 bit apparatuur (en waarschijnlijk het heelal zelf).

@Sander van Voorst @scsirob 18 januari.
Het staat dus fout in het artikel?
Ik zag ook 18 in de google groups staan.

Mijn Android Google Calender werkt overigens tot en met 2036, daarna geeft hij de melding:
"Ongeldig datumbereik. Geldige datums invoeren van 01-01-1902 tot 31-12-2036"

Mijn Android Google Calender werkt overigens tot en met 2036, daarna geeft hij de melding:
"Ongeldig datumbereik. Geldige datums invoeren van 01-01-1902 tot 31-12-2036"

Dat is een veiligheidsmarge. Als je de tijd instelt op een moment een paar minuten voordat de timestamps "op" zijn, dan loopt de tijd vanzelf en paar minuten door, waarna het opeens fout gaat. Door deze oplossing moet je je telefoon meer dan een jaar aan laten staan voordat er dingen kapot gaan.

Ik vermoed dat de (veel kleinere; 13 december 1901) veiligheidsmarge voor 1902 dient omdat er vast ergens code rondslingert die er blind vanuit gaat dat ie altijd de timestamp "yesterday" of iets dergelijks kan berekenen. (Of misschien is het voor gebruikers gewoon minder verwarrend als de kalender begint op 1 januari dan halverwege een maand?)

Kan best fout in mijn programma geweest zijn. Destijds was de toegang tot reference informatie wat lastiger. Geen Google, geen github, geen Stack Overflow. Alleen die paar boeken die je op de kop getikt had. Close enough

64 bit is overdreven, met een unsigned 32 bit int houden we het ook wel even vol.

Alleen vervelend als je negatieve getallen gebruikt hebt voor data van voor 1970...

Maar ja, op dat moment is een int32 ook al niet echt handig want dan kun je maar terug tot ongeveer 1902...

...wat dan grappig genoeg al weer een hele tijd stiekum best wel handig is voor geboortedata etc.
Ik kan me zo voorstellen dat er wel wat ranzig programmeerwerk gaat breken op een hack als dat.

...En kom op zeg, zet dat kreng één keer over naar 64bit en we zijn echt definitief van het gedonder af.
Nog niet eens bijster lastig daar een compatibility layer voor oudere software omheen te hannessen voor de komende 20 jaar, dan is tegen die tijd zelfs de meest weerbarstige legacy-rommel wel een keertje dood

...wat dan grappig genoeg al weer een hele tijd stiekum best wel handig is voor geboortedata etc.

Er zijn drie soorten "tijd": datum ("kalender"), tijd ("klok") en datumtijd (een specifiek moment). Unix timestamps (een betere naam zou datetimestamps zijn) gaan over het vastleggen van specifieke momenten: zowel de dag als de tijd waarop iets gebeurt / gebeurde. Ik geloof meteen dat er talloze situaties zijn waarin een computer een (machine-readable) datum van voor 1902 wil vastleggen. Maar ik heb enige moeite een voorbeeld te bedenken waarvoor je een (machine-readable) datumtijd van voor 1902 wil vastleggen. Zelfs een database van geboortecertificaten zal waarschijnlijk het moment van geboorte vastleggen in twee losse datum en tijd velden (niet in een gecombineerd datumtijd veld), omdat dingen als "wie is jarig op 1 januari" dan veel makkelijker te verwerken zijn.

...En kom op zeg, zet dat kreng één keer over naar 64bit en we zijn echt definitief van het gedonder af.

Mee eens.

Nog niet eens bijster lastig daar een compatibility layer voor oudere software omheen te hannessen voor de komende 20 jaar, dan is tegen die tijd zelfs de meest weerbarstige legacy-rommel wel een keertje dood

Niet mee eens; ooit van Windows XP gehoord? Het lijkt erop dat die na 20 jaar nog steeds volop in gebruik zal zijn. Y2K heeft aangetoond dat grote bedrijven gigantisch lang oude systemen blijven draaien; die hebben zich immers al talloze jaren bewezen. Oude code wordt in hoog tempo zeldzamer, maar echt volledig buiten gebruik raken (zelfs als we musea niet meetellen) duurt gruwelijk lang.

Ik ben met je eens dat het niet *hoort*. Durf jij met zekerheid te stellen dat niet hier en daar een of andere knurft het wél gedaan heeft, gewoon omdat het het eerste is wat ie met z'n lamme kop bedacht? Sorry, maar ik vertrouw er liever niet op dat programmeurs nooit ergens een rare keuze maken

MBT je laatste paragraaf: sorry, dat is ook helemaal waar. Maar in bestaande applicaties gaan we er toch niets aan veranderen totdat iemand op z'n minst met een nieuwe library compiled. Nu iets opzetten wat in elk geval 'oude' meuk gewoon de uit time() verwachte resultaten aanlevert, en tegelijkertijd moderner applicaties al future-proof maakt, maakt dat in elk geval het probleem zich niet nog verder uitspreidt (en door natuurlijk verloop zelfs aardig ingedamd raakt).
Dat er dan nog steeds iemand door een zwik oude mainframes heen moet (je zult wel gelijk hebben, die oude draken draaien in 2038 zo hier en daar nog ) om oude applicaties aan te passen ontkom je sowieso niet aan, maar de meeste systemen die niet óf ergens in een gigantisch hoofdkantoor in de kelder 40+ jaar hetzelfde staan te doen, dan wel als onderdeel van SCADA toepassingen of specialistische apparatuur (het aloude voorbeeld van de cnc machine of MRI-scanner) tot op de draad versleten worden, kennen een verloop korter dan 20 jaar.

De bedrijfsadministratie is óf een keer overgezet, óf wordt gevoerd in een (min of meer ) ondersteund pakket waar dit nog wel aangepakt kan worden.
Juist de consumentenappratuur/software waar daags na de laatste levering (en doorgaans eerder) geen bug meer in geplet gaat worden heeft er nog wel de meeste baat bij als we in de komende vijf jaar helemaal 'over' zijn. Dat hoeft geen twintig jaar mee, vijftien eigenlijk ook zelden, maar tien al weer vaak genoeg. Dus juist om daar weer heel veel verkwisting en onnodig weggedonderde troep te voorkomen zou het wel mooi zijn dit nu op te lossen.

Hoewel dat natuurlijk enigszins logisch is, is epoch makkelijker om mee te rekenen en te programmeren in veel aspecten. Je kan gewoon rekenen met seconden die makkelijk om te zetten zijn in dagen ( optellen, aftrekken e.d.), en hoeft geen logica te hebben voor schrikkeljaren e.d. (of zelfs enig besef van maanden en jaren).

Hoewel apparaten krachtiger worden, kost rekenen tijd en elektriciteit, als je dat kan besparen moet je dat doen

Plus het feit dat een timestamp in seconden een stuk makkelijker sorteert; geen gezeik met alle variabelen aflopen o.i.d., je pakt gewoon van groot naar klein of vice versa.

Iso8601 tijstip sorteert net zo eenvoudig. 2017-07-14:07:11:34.450000
Wat ik niet snap is dat mensen datummapen nog zo vaak als dd-mm-yyyy aanmaken. En dan gaan zoeken wat de meest recente map is 😂.

En hoe doe je het als je iets 'exact' op de zomertijd wissel wilt opslaan? Wil je het goed doen, moet je tijdzones erbij pakken. En kun je dan nog makkelijk sorteren?

Zet deze tijden dan maar eens programmeer-technisch op volgorde?
- 2017-07-14T09:43:33-02:00
- 2017-07-14T06:43:33+00:00
- 2017-07-14T09:43:33+02:00
Dan is dit eenvoudiger te sorteren:
- 1500032613
- 1500014613
- 1500018213

Waar het ook maar een béétje een internationaal karakter heeft, als wij nauwkeuriger moeten sorteren dan dag (en zelfs dan zo hier en daar, al kan dat rare gevolgen hebben als een document wel local time datum/tijd bevat) gaat dat gewoon op UTC.
...Al moet ik zeggen dat datum eigenlijk altijd meer dan nauwkeurig genoeg is, dus heel veel doe ik er ook niet mee. En ik denk dat dat voor verreweg de meeste gevallen geldt.
Zo niet wil je ook niet een tijdzone noteren maar gewoon alles netjes noteren zoals het hoort, dus 2017-07-14:07:43:33Z enzovoorts

Niet zo moeilijk, gewoon sorteren op ingebakken CreatedTime
Welke naamgeving je dan ook gebruikt, de sortering klopt.

Dat werkt niet, je kan dan nooit meer iets met terugwerkende kracht aanmaken.

Oo jawel File.SetCreationTime en er zijn ook verschillende tools voor die je leven makkelijker maken daarvoor. Niet dat het handig is, maar het kan wel.

Forensisch gezien niet, door de journal, maar voor gebruik in Explorer wel in ieder geval.

Goed, je hebt gelijk. Ik had het anders moeten formuleren:
"Dan kan m'n moeder, zonder hulp van mij of andere enthousiastelingen, niet meer een map met terugwerkende kracht aanmaken en sorteren op datum."

Ik vind sorteren op datum wel een erg geavanceerde handeling voor je moeder

Met terugwerkende kracht aanmaken?
Dat is handig.!
Vandaag met terugwerkende kracht aanmaken, dan zit het in de backup van gisteren

En dan ga je ervanuit dat mensen georganiseerd leven.
Even een lijstje mappen kopiëren naar een andere plek en je bent de created timestamp kwijt.
Of een maand terugwerken, of iets updaten in een map en je volgorde ligt weer overhoop.

Dat werkt prima als het een string is waarin je het opslaat, maar als je het als struct doet en elke keer string concats moet gaan doen om te sorteren is dat lekker averechts en een stuk "slomer". Nou zou je allerhande kunstjes kunnen uitvoeren om de boel onderwater anders op te slaan zodat dat niet nodig is, maar is dat niet net wat we juist nu al doen met integers?

Komt nog bij dat er genoeg applicaties met een rtc zijn waar opslag wel beperkt is, denk aan microcontrollers in nagenoeg elk apparaat dat je gebruikt en tijd moet bijhouden.

[Reactie gewijzigd door Merethil op 14 juli 2017 08:00]

Er zijn betere manieren om zo'n struct te sorteren zonder het eerst om te zetten naar een string.

En aangezien de tijd veel gebruikt word om mee te rekenen is opslaan als een string helemaal niet handig. Voor veel toepassingen is overgaan naar 64 bit integer veel beter. Daarmee kun je makkelijk rekenen en sorteren.
En als het dan gedisplayed moet in een voor ons leesbaar formaat, dan zet je het op dat moment maar om naar een string.

Als je berekeningen moet gaan doen op basis van strings of structs, dan krijg je alleen maar meer bugs en kost het ook nog meer rekentijd.

[Reactie gewijzigd door gjmi op 14 juli 2017 07:41]

Dat was dus mijn punt: op dit moment is het een integer en dus prima mee te werken. Een struct gebruiken is prima voor je weergave, maar onderwater is een integer (liefst idd 64bit) het best.

Waarom iemand van zoiets een struct zou willen maken is me sowieso niet duidelijk, weergave != opslag....

Maak nu niet de zelfde fout en zorg ervoor dat het een ' oneindig ' getal kan worden. Anders zit je in jaar 9239478432559345 opnieuw met hetzelfde probleem.

Maak nu niet de zelfde fout en zorg ervoor dat het een ' oneindig ' getal kan worden. Anders zit je in jaar 9239478432559345 opnieuw met hetzelfde probleem.

Daar is al aan gedacht.

maak je daar maar geen zorgen over. als ik het wel heb gaat de aarde nog maar 4.5 miljard jaar mee, en dat halen we als mensheid zeker niet als we zo doorgaan ....

om het dan niet over legacy software te hebben (128bit dan maar doen tegen die tijd?)

Ik sla m'n foto's altijd op met epoch timestamps ;D
(Oké niet helemaal waar, maar het sorteert wel prima!)

Tijdverschillen uitrekenen is ook eenvoudiger.

Tijdverschillen uitrekenen is ook eenvoudiger.

Is het niet zo dat door die epochtijd er geen tijdsverschil is ?
Dat wij mensen nu last hebben van de meridiaanlijnen, hoeft voor een machine niet uit te maken.

Een actie op 1515151515 zal overal ter wereld tegelijkertijd uitgevoerd worden.
Dat het nu hier lunchtijd is, en in de VS borreltijd, maakt voor de machine geen drol uit.

Hij bedoelt tijdsverschillen tussen tussen 2 tijden. Dus 2 uur geleden was 'current - 2 * 60 * 60'.

Denk niet dat hij/zij het over tijdszones heeft

[Reactie gewijzigd door xChOasx op 14 juli 2017 10:12]

Klopt

Dat kan maar is nergens voor nodig, lang niet altijd praktisch en is onnodig duur zoals @Niet Henk hierboven al aangaf. Als we een 128 bit int gebruiken hebben we genoeg ruimte om:
1. Tijd systeembreed in nanoseconde resolutie bij te houden
2. Van wikipedia:
Systems employing a 32-bit type are susceptible to the Year 2038 problem, so many implementations have moved to a wider 64-bit type, with a maximal value of 263−1 corresponding to a number of seconds 292 billion years from the start of Unix time.

Wikipedia heeft het over een 64 bit int en second resolution. Maar rek dat op naar 128 bit en je hebt én nanoseconde resolutie én genoeg tijd in die resolutie voor talloze generaties na ons.

[Reactie gewijzigd door Jeanpaul145 op 14 juli 2017 06:54]

Het probleem is dat wanneer je de resolutie aanpast, alle al bestaande timestamps die om wat voor reden dan ook bewaard moeten blijven omgezet moeten worden... iets wat niet hoeft na een eenvoudige change van INT32 naar INT64.

Tevens werkt dat niet voor microcontrollers, die zijn dan constant bezig om timestamps te ticken, elke nanoseconde... Die hebben wel wat beters te doen (met de minimale capaciteit die ze hebben) ;-)

Goed punt, en dit is dan ook wellicht het punt waarop er meerdere impls moeten komen. Want je hebt gelijk, een embedded systeem heeft die resolutie vaak niet nodig.

Maar werkpaarden mogen wel standaard zo'n resolutie aan boord hebben; Sterker nog, ik zou het graag nog verder richting Planck time resolutie gaan zodat ik m'n metingen nauwkeuriger kan uitvoeren.

Sterker nog, ik zou het graag nog verder richting Planck time resolutie gaan zodat ik m'n metingen nauwkeuriger kan uitvoeren.

Dat is de tijd waarin een foton in een vacuüm (hoogste snelheid mogelijk) een Planck lengte (korste afstand mogelijk) aflegt. Dus, met alle respect en zo, maar dat is echt volkomen overbodig (en zinloos en absurd en, oh ja, onmogelijk).
1 s = 1 s
1 s = 1.000 ms (milliseconde)
1 s = 1.000.000 µs (microseconde)
1 s = 1.000.000.000 ns (nanoseconde)
1 s = 1.000.000.000.000 ps (picoseconde)
1 s = 1.000.000.000.000.000 fs (femtoseconde) [1 fs ≈ 0.22 × length of shortest laser pulse]
1 s = 1.000.000.000.000.000.000 as (attoseconde)
1 s = 1.000.000.000.000.000.000.000 zs (zeptoseconde)
1 s = 1.000.000.000.000.000.000.000.000 ys (yoctoseconde) [hier houdt de naamgeving op]
1 s = ...
1 s ≈ 18.550.000.000.000.000.000.000.000.000.000.000.000.000.000 planck times

Een paar dingetjes:

1. Lezen is blijkbaar nog een hele kunst. Ik schreef "richting Planck time" en niet "ik wil Planck time resolutie". Maw, ik zou voorlopig ook wel tevreden zijn met bv femtosecond of picosecond resolutie.

2. Voor jou is het blijkbaar overkill ja. Voor mij, absoluut niet. Af en toe is het zo verkeerd nog niet om je in te beelden dat anderen dingen willen/nodig hebben die jijzelf niet nodig hebt

Ik schreef "richting Planck time" en niet "ik wil Planck time resolutie". Maw, ik zou voorlopig ook wel tevreden zijn met bv femtosecond of picosecond resolutie.

Waarom roep je überhaupt "Planck time" als wat je probeert te zeggen werkelijk niks met Planck tijd te maken heeft!? Zeg dan gewoon "veel nauwkeuriger" of "veel hogere resolutie". Begrijpelijk schrijven is blijkbaar net zo goed een hele kunst...

Voor jou is het blijkbaar overkill ja. Voor mij, absoluut niet.

Je schreef "werkpaarden mogen wel standaard zo'n resolutie aan boord hebben". Ik neem aan dat je het daarbij over zware maar reguliere ("off the shelf") computerapparatuur hebt, dus niet over extreem specifieke lab apparatuur (in de context van custom-designed machines heeft het woord "standaard" immers geen betekenis). Dus dan ben ik wel heel nieuwsgierig wat je zou willen meten met zelfs maar picoseconde-resolutie (de minst-nauwkeurige die je net specifiek noemt).

Overigens heb ik hoe dan ook slecht nieuws voor je:

• NTP (bij mijn beste weten de manier waarop alle computerapparatuur zijn klok gelijkzet) heeft, puur op protocolniveau, slechts 32 bits voor de fractie van een seconde en dus een maximale resolutie van 1 sec / 2^32 ≈ 233 ps (maar in de praktijk mag je blij zijn om je klok op 1 ms gelijk te krijgen).
• Anders dan een relatieve tijd (verschil tussen twee momenten) kun je een absolute tijd (een specifiek moment) per definitie niet vastleggen met een precisie groter dan 9.192.631.770 Hz (1 sec / 9.192.631.770 ≈ 109 ps), want dat is de frequentie waarop cesium atoomklokken werken en de officiële manier waarop "hoe laat is het nu?" wordt bijgehouden.

[Reactie gewijzigd door robvanwijk op 15 juli 2017 15:49]

ik zou zelf kiezen voor een seconde integer en een nano seconde integer (dus 2 integers), hoevaak heb je de seconde nodig samen met nano seconde en hoevaak alleen 1 van beide

Nou, toevalig bevind ik me in een situatie waarin ik beide nodig heb

Zoiets basis als dit veranderen moet nu al beginnen en niet, zo als het waarschijnlijk gaat gebeuren, om het laatste moment zodat alle legacy software ineens niet meer werkt

Het is juist makkelijk dat de secondes, uren, dagen etc voortkomen uit 1 variabele: ticks.

Maak er een 64 bit integer van (in .net is dit al het geval) en het gaat nog heel lang duren voordat dit een probleem word.

Het ging hem helemaal niet om geheugen ruimte. Jij denkt aan y2k waar we 1990 gewoon als 90 gingen opslaan om geheugen te besparen. De epoch time heeft enorm veel voordelen doordat je voor geen enkele bewerking ook maar enige omzetting moet doen. Het enige moment dat een omzetting noodzakelijk is, is als je deze datum human readable wenst te maken. 20170714065634123 bevat 17 karakters tegenover de 10 van de epoch en is niet duidelijker leesbaar. Ga je er speciale tekens in plaatsen wens ik je veel plezier om computersoftware ermee te laten rekenen.

[...]20170714065634123 bevat 17 karakters tegenover de 10 van de epoch en is niet duidelijker leesbaar.[...]

Sterker nog, de epoch waarde neemt (nu nog) maar 4 Bytes in beslag.
Zo'n string zonder opmaak al gauw 18 en in de praktijk nog veel meer (opmaak + container voor de string)

je interpreteert het verkeerd om. jij doet nu Human time -> Unix Epoch... maar computers hebben niet zoveel met 'onze notatie', die gebruiken ze alleen om ons te vriend te houden ;-)

Snel, wat is de voorgestelde datumnotatie voor het begin van de eerste dag van de volgende maand.

daar is geen notatie voor alleen berekening strtotime('+1 month', strtotime(date('Y-m-01 00:00:01'))); (in php)

Ik had het over de notatie gesuggereerd door Anoniem: 636203 in de root van deze thread.

.edit: en @hcQd verzaakt het om zijn eigen vraag te beantwoorden. Typisch .

[Reactie gewijzigd door .oisyn op 15 juli 2017 16:50]

Men heeft dit vroeger bedacht omdat het geheugen ruimte bespaarde, maar dat is tegenwoordig niet meer relevant, zelfs niet op kleine apparaten.

Ze nemen nu al veel te veel ruimte in beslag, en jij wilt ze nog meer ruimte gaan geven? Als ik alleen al denk aan de vele logregistraties met al die miljoenen timestamps die ik zelf onder beheer heb staan.... laat staan als je ze wereldwijd opslaat.

Dit is een hele efficiënte opslag methode.

Ik stel voor dat we gewoon een struct gebruiken met integers voor jaar / maand /dag, uren / minuten / seconden / milliseconden. Ongeveer zoals ISO 8601 dus.

Alleen werkt hardware zo niet. Die werkt in tikken. Dus je zal hoe dan ook ergens een vertaalslag moeten maken.

Volgens mij doen hogere programeertalen overigens al lang wat jij voorstelt. Denk aan Java en C#/.NET. Maar op hardware en driver niveau zul je toch echt met tikken moeten werken, en de kernel is dan het eerste niveau waar de vertaalslag kan plaatsvinden.

Een seconde na dat moment zal dus niet meer in Unix time uitgedrukt kunnen worden en volgt er een integer overflow waarna het maximale negatieve getal getoond zal worden.

Het verhaal over een integer overflow klopt niet helemaal. Bij een signed integer, dus een integer die ook negatief kan, betekent een integer overflow in het negatief schieten: van het hoogst mogelijk naar laagst mogelijk, dus een negatief getal.

verhaal hieronder klopt niet helemaal maar laat het staan voor context mbt de discussie hieronder
Echter wordt voor de epoch time een unsigned integer gebruikt, die niet negatief kan. Het laagtste getal in een dergelijke integer is 0. 19 januari 2038, om 04:14:07 zal dus de overlow uitkomen op 0 in epoch time, oftewel 1 januari 1970

Edit: de reacties wijzen me er terrecht op dat het bovenstaande niet helemaal klopt. Ik heb even wat verder nagezocht, en het klopt inderdaad niet helemaal.

De unix epoch stamt uit de tijd dat er nog geen unsigned integers waren. Het is dus wel een signed integer, en kan dus negatief overflowen. Om compatibility redenen is dit zo gelaten, nadat signed integers gemeengoed waren. Bijkomend voordeel van signed behouden bij de stap naar 64-bits integers ook heel veel tijden in het verleden aangeduid kunnen worden, als in hoe veel seconden vóór 1 januari 1970

[Reactie gewijzigd door roger128 op 14 juli 2017 13:38]

Echter wordt voor de epoch time een unsigned integer gebruikt

HOERA, 10 punten voor de eerste correcte reactie!

FOUT! de Unix Epoch is signed.
Dat komt omdat unsigned pas in 1978 is uitgevonden in

Simpele berekening verteld het heel duidelijk:
signed: 2147483647 = 68 jaar = 1970 + 68 = 2038
unsigned: 4294967295 = 136 jaar = 1970 + 136 = 2106

Op 64bit systemen is time_t trouwens meestal al 64bit.

[Reactie gewijzigd door DJMaze op 14 juli 2017 12:36]

[...]Het verhaal over een integer overflow klopt niet helemaal. Bij een signed integer, dus een integer die ook negatief kan, betekent een integer overflow in het negatief schieten: van het hoogst mogelijk naar laagst mogelijk, dus een negatief getal.

Hiermee ben ik het volledig eens.

Echter wordt voor de epoch time een unsigned integer gebruikt, die niet negatief kan. Het laagtste getal in een dergelijke integer is 0. 19 januari 2038, om 04:14:07 zal dus de overlow uitkomen op 0 in epoch time, oftewel 1 januari 1970

Ik maakte me ook de bedenking wat het nut was van een signed integer.
Echter, is het dan niet zo dat de maximale waarde 2³²-1 is i.p.v. 2³¹-1 ... en het dus gaat over 7/2/2106 6:28:15.
Gezien het feit dat er blijkbaar iets bestaat als 'year 2038'-problem, zal mijn redenering waarschijnlijk wel een fout bevatten... ik ben nieuwsgierig waar ze zit.

time() is een functie in C die een time_t oplevert. time_t is (helaas?) niet duidelijk gedefinieerd in de standaard; echter in UNIX en andere POSIX-compliant systemen is time_t gedefinieerd als een signed integer (en dus 32 bits op 32-bits systemen, en 64 bits op 64-bits systemen). Ik vermoed dat dat komt omdat het unsigned type pas later bedacht is dan deze functie.

[Reactie gewijzigd door RedPixel op 14 juli 2017 12:15]

HOERA, 10 punten voor de eerste correcte reactie!
Inderdaad, de Unix time wordt uitgedrukt als een unsigned.
Dus we kunnen nog wel even vooruit. Maar... zoals vaak zijn er vast een groot aantal slordige programmeurs die dit even over het hoofd gezien hebben. Net als de domme programmeurs het jaar 2000 probleem hebben veroorzaakt kunnen ze in 2038 voor het probleem zorgen dat een foutief geprogrammeerde time (integer in plaats van unsigned) de tijd negatief wordt, terwijl hij in een unsigned nog vrolijk verder kan tikken tot vooraan in de 22ste eeuw.
We kunnen alleen maar hopen dat tegen dat de domheid van die programmeurs aan het licht zou komen alle 32-bit integer implementaties door 64-bit zijn vervangen. (Dat is nu op 64-bit machines nog steeds NIET het geval.)

Ouch... even een update: het blijkt dat in vele implementaties time_t is gedefinieerd als een signed integer. Dat is jammer. Ik herinner mij van veel vroeger dat het een unsigned was. Het was op oude 16-bit machines bovendien ook nog een long (anders zou de tijd heel snel afgelopen zijn).

[Reactie gewijzigd door pauldebra op 14 juli 2017 18:08]

Vroeger bestonden er geen unsigned 32-bit integers in C, enkel signed.

Maar... zoals vaak zijn er vast een groot aantal slordige programmeurs die dit even over het hoofd gezien hebben. Net als de domme programmeurs het jaar 2000 probleem hebben veroorzaakt kunnen ze in 2038 voor het probleem zorgen dat een foutief geprogrammeerde time (integer in plaats van unsigned) de tijd negatief wordt, terwijl hij in een unsigned nog vrolijk verder kan tikken tot vooraan in de 22ste eeuw.

Dus die van het Y2k probleem waren dom, die programmeurs die zogenaamd een signed int ipv een unsigned int gebruiken voor time_t zijn dom (even los van het feit dat time_t gewoon signed is, maar daar was je inmiddels al achter), maar de programmeurs die een unsigned time_t gebruiken zijn niet dom? Waarom is 2038 wel een probleem, maar 2106 niet?

By the way:

integer in plaats van unsigned

Een unsigned integer is net zo goed een integer. Het woord integer zegt vrij weinig over of het signed is of niet.

[Reactie gewijzigd door .oisyn op 15 juli 2017 16:57]

De domheid van het Y2K probleem was dat programmeurs dachten dat software niet tot in het jaar 2000 zou meegaan, dus daar hoefde geen rekening mee gehouden te worden.
Het jaar 2038 probleem bestaat alleen als over 21 jaar er nog systemen zijn die met 32 bit integers werken. Wellicht was de veronderstelling dat die er niet meer zouden zijn ook een beetje dom.
Ik heb vroeger (ik spreek over iets als 30 jaar geleden) geleerd dat de tijd unsigned was. Dat lijkt nu niet meer zo te zijn, maar hoe dat zo gekomen is weet ik ook niet.
Ik hoop er nog ter zijn in 2038 (ben dan nog net geen 80). Benieuwd wat er da gebeurt...

Interessant dat de unix timestamp signed is. Unsigned kan ie tenminste nog 2x zo lang mee.

Kijk eens hier. Signed heeft zijn voordelen zeker als we moeten switchen naar 64bit na 2038.

Wat moeten we zonder stackexchange! Makes sense thx voor de link.

Waarom is 1 januari 1970, UTC het betreffende beginpunt?

Gewoon overstappen op Rels, blijkbaar werkt dat in de verre verre toekomst nog steeds prima!

Wat bijzonder feit dat ik dit heb mogen meemaken!

Eindelijk weer eens een echt tweakers feitje . Ga ik mooi nog mee maken, al ben ik dan wel 79.
Hang de boel aan GPS of zet de teller weer op 0. Veel dbase systemen doen dat ook. Herinner me de gevallen van mensen uit 1901 geboren, die waren met de millennium bug ineens 01. Toch lastig als je medicijn dosis is afgestemd op een pas geborene.

Haha. Startdatum gaan gebruiken. Maar dan ook in het dagelijks leven. Weg met de huidige kalender.

Dit artikel had natuurlijk een stuk leuker geweest als aankondiging zodat de liefhebbers hun wekker hadden kunnen zetten. Dit is berichtgeving over een feestje wat je gemist hebt.

Wel grappig dat iedereen het over 32 bits heeft (binair) en dat het artikel zich druk maakt over 1500000000 seconden... een echte geek zou een mooi binair getal meer moeten aanspreken!

Ik ben het wel eens met het feit dat dit een software en niet een hardware probleem is.
En dat expansie naar 64 bits waarde het makkelijkste is.

Probleem blijft met oude databases/files etc.. waar alles nog wel in 32 bit records zit.
Maar wie weet met een "truukje" ook wel te fixen... 32bit veld is altijd voor 2038. Nieuw 64 bit veld toevoegen voor nieuwe data en 32 bit veld op 0 houden.

Wel grappig dat iedereen het over 32 bits heeft (binair) en dat het artikel zich druk maakt over 1500000000 seconden... een echte geek zou een mooi binair getal meer moeten aanspreken!

Nice one . Noteer in je agenda: op 14 jan 2021 om 9:25:36 is het 0x60000000 oftewel 1100000000000000000000000000000