Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 162, views: 44.277 •
Submitter: nomam

De Unix-timestamp heeft op zaterdag 14 februari 0:31:30 Nederlandse tijd de waarde 1234567890 bereikt. Voor vele Unix-adepten voldoende reden om wereldwijd 1234567890-feesten te organiseren, maar er komt wel een 'Unix Millennium Bug'.

Klok-mechaniekHet timestamp-systeem van Unix telt het aantal seconden dat is verstreken sinds 1 januari 1970 om 0:00 uur UTC en legt deze vast in een 32-bit integer. Dit tijdstip met de waarde 0 wordt ook wel de Unix-epoch genoemd. Sindsdien wordt de timestamp elke dag verhoogd met 86.400 seconden.

De gebruikte 32bit-notering voor de timestamp heeft echter een nadeel: op 19 januari 2038 om 03:14:08 UTC is de teller vol en zal een overflow het gevolg zijn. De 'Unix Millennium Bug' kan echter al eerder dan 2038 problemen opleveren. Zo zullen bijvoorbeeld systemen die in 2028 berekeningen voor tien jaar vooruit willen maken, al tegen de limiet oplopen. Inmiddels wordt er al hard gewerkt aan een 64bit-methode voor onder andere Linux-systemen. Volgens Linux-guru Alan Cox zal een timestamp-notering in 64bit meegaan 'tot de zon is opgebrand'.

Zover is het nog niet. De 1234567890-timestamp blijkt voor Unix-aanhangers reden genoeg om een feestje te geven. Wereldwijd zijn er tal van bijeenkomsten belegd, zo blijkt uit een overzicht op de website 1234567890day.com. In Nederland ziet studentenvereniging De Bolk voldoende reden om Valentijnsdag te verruilen voor een 1234567890-borrel.

Reacties (162)

Reactiefilter:-11620142+130+216+30
xD, ook precies op die tijd gepost natuurlijk!
Ja, het was alleen wel leuk geweest om het even van tevoren te weten :)
Een beetje nerd wist dit natuurlijk al dagen/maanden van te voren ;)
sinds 1 januari 1970 ;)
Een beetje tweaker heeft het topic, dat kort na opening gesloten werd, op het forum voorbij zien komen waardoor ie het wist ;)
Daar hebben we natuurlijk automagisch functies voor :P
pfff, niet een FPposter die met z'n vinger boven de send toets zit om het te versturen :P
Valt me eerlijk gezegd wel een beetje tegen ;)
Je hebt de database aangepast met dit speciale tijdstip :P
Fijn 1234567890 allemaal! *O*
+1!

Ik heb nog niets van die feesten gehoord maar dat kan misschien nog komen...

[Reactie gewijzigd door MaestroMaus op 14 februari 2009 10:09]

Bij programmeren kom je anders regelmatig met de UNIX timestamp in aanraking, bij PHP en database's als MySQL bijvoorbeeld.
dammid ben ik dan weird als ik daar dagelijks mee in aanraking kom
Ook op niet unix system, zoals windows, kom je in aanraking met unix timestamps.
niet 1 iets of wat normale mens die daar ene moer om geeft, zelfs 90% van de tweakers heeft nog nooit op een unix bak gewerkt, laat staan in aanraking gekomen met die timestamp
heeft ook ermee te maken dat de meeste die zichzelf een 'tweaker' noemen eigenlijk alleen gamertjes zijn en denken verstand te hebben van computers.

alleen ikzelf als pro-actief *nix user kan 't me eigenlijk geen moer intresseren dat 't die waarde is gehaald, de digitale klok is ook elke dag op 13:37, so whut?

[Reactie gewijzigd door teh_twisted op 14 februari 2009 21:21]

onder tweakers versta ik hardware en software tweakers, niet de gewone forum/frontpage bezoekers.
WOS heeft toch 44.907 posts.

Dat is voor ij genoeg aan te nemen dar er best wel een hoop ux mensen hier op T.net rondwarreld. Vergeet niet dat T.Net een mooie KnowledgeBase is.
Om het halen van 1234567890 interessant te vinden maakt het niet uit of je pro-actief bent en of je een *nix user bent. Je moet vooral zin in een feestje hebben. :)
De gebruikte 32bit-notering voor de timestamp heeft echter een nadeel
Gelukkig betrekkelijk simpel op te lossen door die int te vervangen door een 64-bit model. En ik vermoed dat ons dat wel lukt voor 2038 ;) (We zijn zelfs al vrij aardig op weg, itt het year-2000 probleem waar we niet ruim 40 jaar vantevoren aan bezig waren ;))

[Reactie gewijzigd door CyBeR op 14 februari 2009 00:35]

Tuurlijk, moeten alleen even alle software herschrijven/hercompileren die er ooit gemaakt is en die rekening houd met 32 bitjes en geen bit meer.

Niet alleen bij software loop je tegen een probleem er zijn ook genoeg bestandsformaten die moeten worden aangepast. Ook software die berekeningen doen in de toekoemst zoals voor het voorspellen van het weer zullen al eerder in de problemen komen.

[Reactie gewijzigd door Blackspot op 14 februari 2009 00:57]

Ja. Heb je helemaal gelijk in. Maar gelukkig hebben we nog 29 jaar de tijd :P
Niet als je systeem, programma's en databases om moeten kunnen gaan met de datum 2038 of verder. En die situatie is vandaag al reëel dus haast is geboden.
Ja hoor. Ik heb nu en dan te maken met verre toekomstige data, en pakweg het jaar 2039 is in MySQL gewoon illegaal (illegal timestamp). Bijzonder vervelend.

Desalniette--, een fijn 1234567890 iedereen.
En hoe zit dat dan met data ver in het verleden? Wat wel vaker voor komt.

-1234567890 - 18 November 1930 00:48:02

Maar als je data hebt die -32 bits gaat...
Heb je daar ervaring mee?
Ik hoop (zou het even moeten proberen) dat postgresql en andere wat "professionelere" databases het inmiddels al wel kunnen.
Volgens mij heb ik dit rond 1990 ook regelmatig gehoord

en diezelfde personen zaten in '99 toch wel met de handen in het haar, ergens een foutje in hun planningen en deadline's
probleem van 'mensen' is dat je tijd makkelijk in kan schatten, maar nooit genoeg over hebt om ruim te zitten :)

Succes met de flame's die nu uit de windowskampen komen, die arme zielen hebben al 10 jaar de unix-community over zich heen om dit soort problemen
Mijn hypotheek loopt 30 jaar en die heb ik net niet voor die tijd vastgelegd, zal mij benieuwen of het goed gaat. ;-)

Thuis heb ik het al wel voor elkaar, al mijn computers zijn in ieder geval 64-bit met 64-bit Linux.

En dat terwijl ik al 10 jaar 64-bit computers in huis heb.

[Reactie gewijzigd door Lennie op 14 februari 2009 13:50]

Toch jammer dat je er NU al tegen aanloopt als je een 30 jaar lopende hypotheek wil berekeken he?
Ook software die berekeningen doen in de toekoemst zoals voor het voorspellen van het weer zullen al eerder in de problemen komen.
Alleen is het voorspellen van het weer voor een periode van langer dan 10 jaar wel érg absurd veel, niet? Een vooruitzicht van een paar dagen kan nog, maar echt niet langer, dus dat zal wel los lopen.
Het gaat niet om de voorspelling zoals wanneer het gaat regenen enzo. Het zijn meer computermodellen over global warming en dat soort lange termijn effecten.
Ik neem aan dat die specifieke programma's daar allang tegenaan zijn gelopen (al voor Y2K), dus die zijn al jaren 64bit bezig.
global warming modellen gebruiken helemaal geen systeem tijd. Daar is tijd gewoon één van de paameters in het model, en dat kan iedere representatie hebben.
global warming modellen gebruiken helemaal geen systeem tijd. Daar is tijd gewoon één van de paameters in het model, en dat kan iedere representatie hebben.

Je zou hierhoor eigenlijk wel een +2 verdienen, want je haalt daarmee ". Zo zullen bijvoorbeeld systemen die in 2028 berekeningen voor tien jaar vooruit willen maken, al tegen de limiet oplopen." totaal onderuit. Immers, of je nou global warming aan het berekenen bent, of olievoorraden, je kunt in je eigen model gewoon ieder jaar vanaf 1970 als basis nemen! Het gaat immers om de verstreken tijd, en niet om de 'juiste' begin-datum.
Dat zou dus waarschijnlijk moeten zijn: software voor het voorspellen van het klimaat, niet het weer.
Klein detail: niet voorspellen, maar verwachten. Veel gemaakte fout als mensen het over meteorologie hebben. ;)
Nee, een veel gemaakte fout door meteorologen. Die denken dat een verwachting goed genoeg is, maar de klant wil toch echt een voorspelling.
Behalve dat een echte voorspelling natuurlijk niet haalbaar is.

Maar goed, klimaatmodellen zijn al zeker 20 jaar 64bit, omdat je een aantal berekeningen gewoon op hogere precisie moet doen (en geheugen is ook al ten minste 20 jaar geen bottleneck, CPU wel)
Tuurlijk, moeten alleen even alle software herschrijven/hercompileren die er ooit gemaakt is en die rekening houd met 32 bitjes en geen bit meer.
De grap is hierbij wel dat we binnen nu en zo'n 5-10 jaar allemaal over gegaan zijn op een 64-bit processor en besturingssysteem. Als men verstandig is zorgt men er in elk geval voor dat met die overgang er altijd een aanpassing meegaat inzake de tijdsafhandeling.
Niet alleen bij software loop je tegen een probleem er zijn ook genoeg bestandsformaten die moeten worden aangepast.
Daar heb je gelijk in, maar dat zou je nu al op kunnen lossen in de software, door het getal als een 32 bit unsigned int te gaan behandelen - dan kunnen we voorlopig nog wel even vooruit dacht ik zo.

Maar ik geef gelijk toe dat zoiets niet meer is dan een noodverband en dat het gebruik van dat soort oplossingen tot een minimum beperkt moet blijven.
Ook software die berekeningen doen in de toekoemst zoals voor het voorspellen van het weer zullen al eerder in de problemen komen.
Inderdaad...

Aan de andere kant mag ik hopen dat men al rekening is gaan houden met de 2038-bug sinds dat de 2YK-bug ter sprake is gekomen - met andere worden de mogelijkheid in de software om te werken met een 64-bit tijd of er al mee werken...
De grap is hierbij wel dat we binnen nu en zo'n 5-10 jaar allemaal over gegaan zijn op een 64-bit processor en besturingssysteem. Als men verstandig is zorgt men er in elk geval voor dat met die overgang er altijd een aanpassing meegaat inzake de tijdsafhandeling.
Ik vrees dat dat niet zoveel uitmaakt. 20 jaar geleden waren er ook genoeg 64-bit computers in omloop (de problemen zullen niet zo snel op je desktop optreden en als dat al zo is, dan zal dat niet zo ernstig zijn als het verkeerd gaat).

Het probleem is eerder al die systemen bij energiebedrijven, banken, etc. die al zo'n 30 jaar worden onderhouden. Even hercompileren is makkelijker gezegd dan gedaan.
Daar heb je gelijk in, maar dat zou je nu al op kunnen lossen in de software, door het getal als een 32 bit unsigned int te gaan behandelen - dan kunnen we voorlopig nog wel even vooruit dacht ik zo.
"Unsigned int"? In, laten we een moderne taal nemen, Java?
"Unsigned int"? In, laten we een moderne taal nemen, Java?
In Java maak je -als het goed- is geen gebruik van het Unix timestamp, daar heb je java.util.Date om een datum/tijd te representeren.

Mocht je toch behoefte hebben om alle 32-bitjes voor de data te gebruiken in Java, dan neem je gewoon een long waarin je de data opslaat. Alleen bij het serialisen moet je wel opletten dat je slechts 32-bit wegschrijft (inlezen is geen issue).

Uiteraard is het een lapmiddel om een timestamp als unsigned te behandelen, maar in een binair formaat kan het net voldoende zijn om heel snel het 2038-probleem op te lossen.

@onox: Dat stel ik ook helemaal niet voor, wat ik aangeef is het gebruik van een signed 64 bit long voor het opslaan van 32-bit unsigned gegegevens :)

[Reactie gewijzigd door Little Penguin op 14 februari 2009 17:05]

In java.util.Date heb je anders wel de constructor Date(long date) en de methode getTime() die een long teruggeeft. Een long is in Java 64-bits.

Volgens mij kun je niet zomaar "eventjes" een int en een long als unsigned gaan behandelen, dan zou namelijk ook de waarde van constanten als Integer.MAX_VALUE en Integer.MIN_VALUE moeten veranderen, wat veel software stuk kan maken.

[Reactie gewijzigd door onox op 14 februari 2009 13:38]

In java.util.Date heb je anders wel de constructor Date(long date) en de methode getTime() die een long teruggeeft. Een long is in Java 64-bits.
Uiteindelijk zal die tijd ergens vandaan moeten komen, die haalt Java ook niet zomaar op magische wijze uit de achtergrondstraling van het universum. Java haalt die tijd gewoon uit een diepere laag van het systeem. Het gaat dus om de zwakste schakel: als uiteindelijk het BIOS 32 bits gebruikt om de tijd op te slaan, dan heeft de Java applicatie net zo goed een probleem.

PS overigens rekent Java in de meeste gevallen met tijden in milliseconden i.p.v. seconden.
Ja alleen word op Unix en linux veel meer gebruik gemaakt van C/C++ dan Java.
Daar heb je gelijk in, maar dat zou je nu al op kunnen lossen in de software, door het getal als een 32 bit unsigned int te gaan behandelen - dan kunnen we voorlopig nog wel even vooruit dacht ik zo.
Echter introduceert dit een veel ernstiger probleem, want hoe ga je data voor 1 Januari 1970 weergeven dan? Als je puur een unsigned int gebruikt zijn dus alle data opeens na 1 Januari 1970. Ik denk dat dat heel veel data zijn...

De 'correcte' oplossing is (zoals ook al vermeld) om een signed 64-bit int te gebruiken. (een long dus) Maar zie dat maar eens in alle systemen er door te krijgen...
Een simpele emulator zal hier toch wel genoeg voor zijn? Op Vista x64 draait ik ook gewoon PS x64 en PS x86. Vista heeft dit ingebouwd dat je toch 32 bits programma's kunt draaien. Weet niet hoe dit bij andere OS'en zit.
Dit gaat om tijdnotatie, tijd dat als 32-bits getal is opgeslagen in bestanden. Heeft dus niets met emulatie te maken.
Een 64 bits time() functie bestaat al lang. Het punt is meer al die systemen waar een dergelijke waarde in voorkomt. Filesystems, databases, bestandsformaten, etc.. Het is niet moeilijk om aan te passen, maar wel gewoon heel erg veel werk.

[Reactie gewijzigd door .oisyn op 14 februari 2009 00:54]

Het gaat met name mis bij filesystemen. Op linux wordt b.v. best vaak ext2 of ext3 (ext2 met journaling) gebruikt. Kijk maar eens hoe dat in elkaar zit:
http://src.opensolaris.or...ommon/sys/fs/ext2_inode.h
143 /*
144 * On-disk inode structure
145 */
146
147 struct ext2_od_inode
148 {
...
152 uint32_t i_atime; /* Access time */
153 uint32_t i_ctime; /* 12: Creation time */
154 uint32_t i_mtime; /* Modification time */
155 uint32_t i_dtime; /* 20: Deletion Time */
Om de binary structure leesbaar te houden onafhankelijk van de gebruikte processor (een disk die geformatteerd is in systeem A moet leesbaar zijn voor systeem B met andere hardware), worden de integers in zo'n disk structuur fixed size gemaakt, onafhankelijk van de natuurlijke woordbreedte van de processor. In het geval van de ext filesystemen worden tijden dus vaak in 32 bits opgeslagen en dat gaat fout in 2038.

Ik vind het trouwens raar dat dit nog steeds zo is op een relatief recent filesysteem als ext3. Ik heb ooit een y2k project moeten doen (in 1998, uiteraard ruim voordat het probleem zou optreden) en daar moesten we expliciet op de 2038-bug testen en fixen. Voor de stokoude besturingssystemen en hardware die banken vaak gebruiken waren toen al gewoon patches beschikbaar.
uint32_t
Staat hier niet gewoon dat men een unsigned integer gebruikt? Dan hebben we toch nog een beetje langer dan 2038?

Waarbij ik overigens wel toegeef dat het wel vreemd is dat een moderner systeem geen rekening houdt met het feit dat de unix time per 2038 problemen kan gaan geven.

Aan de andere kant geeft het unsigned zijn van de tijd al voldoende ruimte om het nog even uit te kunnen zingen - zo'n 60 jaar, in die tijd moet 't toch wel lukken om de boel te fixen...
Je hebt gelijk. Ik had er niet bij stilgestaan dat het probleem in 2038 alleen bij signed integers optreedt. Gelukkig maar :)
Maar ja dan kan je weer geen data van voor 1970 aanmaken. (Niet dat het heel vaak zal voorkomen maar voor geboortedata kan het wel handig zijn.)
Alleen gaat het hier om bestandsgegevens en aangezien dat het niet logisch is om bestanden in het verleden aan te maken...
In het geval van de ext filesystemen worden tijden dus vaak in 32 bits opgeslagen en dat gaat fout in 2038.
Dat is (voorlopig) verholpen in ext4. :)

Van Wikipedia:
... ext4 will have timestamps measured in nanoseconds. This feature is currently implemented in 2.6.23. In addition, 2 bits of the expanded timestamp field are added to the most significant bits of the seconds field of the timestamps to defer the year 2038 problem for an additional 500 years.
Het Linux alternatief voor Valentijnsdag? :P
ja :)
hebben wij ook nog wat om blij om te zijn
Party like it's 19029384756 :+
Hehe, ik zie net dat '1234567890' in de icoon van Google is verwerkt.
Binnenkort zou het logo moeten verschijnen op http://www.google.com/holidaylogos.html
(als je deze pagina na 2009 nog bekijkt, waarschijnlijk: http://www.google.com/holidaylogos09.html ;) ).
edit:
Op dit moment staat het ""gewone" logo alweer op google.com :(

[Reactie gewijzigd door robvanwijk op 14 februari 2009 01:59]

Gelukkig 1234567890!
Fijne Epoch verjaardag :D
Haha, alleen geeks houden zoiets bij. Ik kan ook alleen uit bed komen als er een leuke tijd op het klokje staat 6:54 ofzo. Zal wel een afwijking zijn :)
Dat heb ik ook inderdaad, 12:34 vind ik alleen iets 'mooier' nog :+

Op dit item kan niet meer gereageerd worden.



Populair: Vliegtuig Luchtvaart Crash Smartphones Google Laptops Apple Games Politiek en recht Rusland

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013