Unix-timestamp bereikt 1234567890-waarde

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'.

Het 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)

[jiriw]

Haha Ik zie net dat het in UTC dus nog op vrijdag de dertiende valt. Laat die 'Unix millennium bug' maar komen

Als het goed is, trouwens, worden in 64bit kernels de timestamps al in een 'standaard' integer opgeslagen welke 64 bit is want de integer grootte is afhankelijk van het machine 'word', welke voor 64 bit systemen (goh...) 64 bit is. Echter, niet in alle compiler models wordt aangehouden dat de integer gelijk is aan het machine 'word', dus het kan nog een feestje worden straks.

<Edit voor jj71. Linux kernel 2.6.28.5>
time_t in de linux kernel voor 32 en 64 bit x86 systemen is dus een long int. Zie trace hieronder.
Een long int in een 32 bit systeem is 32 bit, in een 64 bit systeem 64 bit. Dit volgens het LP64 systeem waar GCC gebruik van maakt. M'n verhaaltje klopt dus nog steeds... alleen is time_t long in plaats van int.

/usr/include/linux/time.h:
4 #include <linux/types.h>

/usr/include/linux/types.h:
11 #include <linux/posix_types.h>
81 typedef __kernel_time_t time_t;

/usr/include/linux/posix_types.h:
47 #include <asm/posix_types.h>

arch/x86/include/asm/posix_types.h:
2 # ifdef CONFIG_X86_32
3 # include "posix_types_32.h"
4 # else
5 # include "posix_types_64.h"
arch/x86/include/asm/posix_types_64.h:
33 typedef long __kernel_time_t;
arch/x86/include/asm/posix_types_32.h:
33 typedef long __kernel_time_t;

[Reactie gewijzigd door jiriw op 22 juli 2024 15:39]

[jj71]

In gcc (de meest gebruikte compiler voor Linux en andere Unix-achtige systemen) is een int op een 64-bit systeem gewoon 32 bits, net als op 32-bit systemen. (Alleen pointers zijn groter dan 32 bits).

Dus voor 64-bit Linux geldt je redenering in ieder geval niet.

[brompot758]

Alleen gebruik je voor timestamps een time_t, geen int. Dat zou ook niet werken als je een bestand van een 32 bit systeem krijgt. Of als je 32 bit software op je 64 bit bak draait.

Het probleem zit ook niet zozeer in nieuwe software, daar zijn allang oplossingen voor. Het probleem zit in bestaande software en/of data.

Overigens heeft ook Windows begin januari 2038 soortgelijke problemen, daarin wordt dezelfde time_t gebruikt.

[kimborntobewild]

Zo zullen bijvoorbeeld systemen die in 2028 berekeningen voor tien jaar vooruit willen maken, al tegen de limiet oplopen.

Er zijn programma's zat te bedenken, waarbij 't al veel eerder misgaat. Bij hypotheeksoftware bijvoorbeeld (bijv. met een hypotheek met looptijd van 30 jaar). Maar ook bij berekeningen m.b.t. pensioenen kan men makkelijk 30 jaar in de toekomst moeten kijken (rekenen). Ik noem maar een paar dwarsstraten.

[Reactie gewijzigd door kimborntobewild op 22 juli 2024 15:39]

[Kees]

ik neem aan dat dat soort programma's al niet meer met dit soort limieten werken. Die zullen ook in 1970 al zoiets hebben gehad van 'hey, als ik deze hypotheek van 30 jaar in het systeem zet dan is hij 70 geleden verlopen, laat ik dat eens anders programmeren' en met het milenium achter de rug zal iedereen wel wat beter op dit soort limieten letten

[Dysmael]

De software kan heus wel verder tellen dan 30 en ook verder tellen dan 2038.
Je moet alleen niet op de datum gaan rekenen.

Stel:

Ik leen jou € 2000,- (renteloos) en dat wil ik in 100 jaar terugbetaald hebben.

Dan los je elk jaar (2000 / 100 = ) € 20,- af.
Over 10 jaar heb je (10 * 20 = ) € 200,- afgelost.
In het jaar 2060 heb je ((2060 - [huidig jaar]) * € 20,- = ) € 1020,- afgelost.

Alleen waar [huidig jaar] staat word er naar de datum gekeken. En dan alleen het huidige jaartal. Bij berekeningen pas je niet het jaartal van de computer aan. Dus alleen na het verstrijken van de limiet loop je tegen problemen aan.

[Arnoud Engelfriet]

Precies. Bovendien: waarom sla je de looptijd van een hypotheek op als een time_t? Het lijkt me iets logischer om daar gewoon het aantal maanden of jaren als een int op te slaan.

[VisionMaster]

Als je het eerder aflost op een gegeven moment, dan moeten ze de boete (wanneer van toepassing) en de opgebouwde rente (spaarhypotheek) uitkunnen rekenen tot op de dag.

[jip_86]

Een bank wil toch wel weten wanneer die lening afgelost moet zijn. Ook zal de computer vast wel willen weten dat ze elk jaar 20 euro van jou kunnen verwachten. toch ?

[CyBeR]

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 22 juli 2024 15:39]

[Verwijderd]

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 Verwijderd op 22 juli 2024 15:39]

[Little Penguin]

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...

[JeroenB]

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?

[Little Penguin]

"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 22 juli 2024 15:39]

[onox]

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 22 juli 2024 15:39]

[Herko_ter_Horst]

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.

[NC83]

Ja alleen word op Unix en linux veel meer gebruik gemaakt van C/C++ dan Java.

[DJFreestyler]

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...

[CH4OS]

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.

[Verwijderd]

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.

[Verwijderd]

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.

[albatross]

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.

[Verwijderd]

Ik neem aan dat die specifieke programma's daar allang tegenaan zijn gelopen (al voor Y2K), dus die zijn al jaren 64bit bezig.

[jj71]

Dat zou dus waarschijnlijk moeten zijn: software voor het voorspellen van het klimaat, niet het weer.

[Oboemel]

Klein detail: niet voorspellen, maar verwachten. Veel gemaakte fout als mensen het over meteorologie hebben.

[mashell]

Nee, een veel gemaakte fout door meteorologen. Die denken dat een verwachting goed genoeg is, maar de klant wil toch echt een voorspelling.

[Verwijderd]

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)

[GWTommy]

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.

[thegve]

Dit gaat om tijdnotatie, tijd dat als 32-bits getal is opgeslagen in bestanden. Heeft dus niets met emulatie te maken.

[CyBeR]

Ja. Heb je helemaal gelijk in. Maar gelukkig hebben we nog 29 jaar de tijd

[Verwijderd]

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.

[Verwijderd]

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.

[Verwijderd]

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?

[mae-t.net]

Ik hoop (zou het even moeten proberen) dat postgresql en andere wat "professionelere" databases het inmiddels al wel kunnen.

[FreshMaker]

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

[leuk_he]

Toch jammer dat je er NU al tegen aanloopt als je een 30 jaar lopende hypotheek wil berekeken he?

[Lennie]

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 22 juli 2024 15:39]

[.oisyn]

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 22 juli 2024 15:39]

[berend_engelbrecht]

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.

[Little Penguin]

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...

[berend_engelbrecht]

Je hebt gelijk. Ik had er niet bij stilgestaan dat het probleem in 2038 alleen bij signed integers optreedt. Gelukkig maar

[paulh]

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.)

[Little Penguin]

Alleen gaat het hier om bestandsgegevens en aangezien dat het niet logisch is om bestanden in het verleden aan te maken...

[deadinspace]

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.

[Verwijderd]

Sindsdien wordt de timestamp elke dag verhoogd met 86.400 seconden.

Dit klopt niet helemaal, de Unix timestamp kent geen dagen. Iedere seconde zal het aantal met 1 opgehoogd worden. Niets meer niet minder.

Je kan de Unix timestamp omrekenen naar iedere kalender die je maar wil. Zou je het bekijken als een van onze eigen westerse dagen met onze moderne telling dan is normaal 1 dag 86400 seconden (en dus een overeenkomstig verschil in de Unix timestamp), maar er zijn ook dagen met een seconde minder of meer. (Hoewel minder nog niet is voorgekomen voor zo ver ik weet)

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:39]

[Jory]

Als ik even het wikipedia artikel over unix time (http://en.wikipedia.org/wiki/Unix_time) lees daar onder andere het volgende.

When a leap second occurs, so that the UTC day is not exactly 86 400 s long, a discontinuity occurs in the Unix time number. The Unix time number increases by exactly 86 400 each day, regardless of how long the day is.

Daaronder staat ook een mooie tabel, waarin de unix time twee keer de waarde 915 148 800.00 bereikt.

Het klopt dus wel. (Al zijn het technisch gezien dus geen 86400 "seconden", want niet ieder "getal" staat per definitie voor precies één moment in de tijd, wat een seconde dus wel doet.)

[CH4OS]

Dit klopt niet helemaal, de Unix timestamp kent geen dagen. Iedere seconde zal het aantal met 1 opgehoogd worden. Niets meer niet minder.

Echt, je kan ook op elke slak zout leggen. Je snapt best wat er bedoeld word, maar voor de duidelijkheid dan maar: per dag worden er dus 86.400 seconden omhoog getikt op de Unix timestamp. Overigens klopt die 86.400 ook niet. Een jaar heeft niet op de kop af 31536000 seconden, omdat een jaar eigenlijk 365,25 dag is. Daarom is er eens in de vier jaar een schrikkeljaar om dat verschil recht te zetten. Als we dan toch bezig met de slakken zijn...

[Verwijderd]

Maar dat is een eigenschap van onze eigen kalender en heeft dus in feite niets met de Unix timestamp te maken. Die doet daar allemaal niet aan, die doet gewoon netjes iedere seconde z'n waarde 1 omhoog.

Niets meer niets minder.

Overigens heeft het aantal seconden in het jaar niets te maken met het aantal seconden in een dag. Dat niet iedere dag evenveel seconden heeft is vanwege schrikkelsecondes.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:39]

[dev10]

omdat een jaar eigenlijk 365,25 dag is.

Als we toch zout aan het leggen zijn: een jaar is geen 365,25 maar 365,26 dagen. Vandaar je een keer in de honderd jaar geen schrikkeljaar hebt.

Het jaar 201900 was bijvoorbeeld deelbaar door 4 (= 500) maar ook deelbaar door 100 (= 20). Als een jaar deelbaar is door honderd en door vier, is het geen schrikkeljaar.

@Kef: je hebt gelijk ja.

[Reactie gewijzigd door dev10 op 22 juli 2024 15:39]

[Kef]

2000 was een schikkeljaar, omdat het deelbaar is door 400.

Als je bijvoorbeeld 1900 pakt, die is deelbaar door 4 en 100, maar niet 400. Dit jaar is daarom ook geen schikkeljaar.

[_JGC_]

Je maakt de verkeerde slak dood
Met 365,26 dagen per jaar zouden we juist vaker dan eens per 4 jaar een schrikkeljaar moeten hebben

[Little Penguin]

Als je dan toch bezig bent met zout, dan moet je wel het juiste vaatje pakken. Het jaar is niet langer maar juist korter dan die 1/4 dag.

Een tropisch jaar (de tijd die de aarde nodig heeft om in haar baan om de zon van lentepunt naar lentepunt te draaien) is niet exact 365 dagen. Het is 365 dagen, 5 uren, 48 minuten en 45,1814 seconden = 365,2421875 dagen.

Bron: http://nl.wikipedia.org/wiki/Schrikkeljaar

[Verwijderd]

Waarschijnlijk kort door de bocht.
Maar als ze nu 1 januari 2000 op 0 zetten in de volgende versie van linux.
Is het probleem toch ook opgelost? en binnen 30 jaar resetten ze terug het geheel.

[Little Penguin]

Heel kort door de bocht.

Hoe ga je dan om met de bestanden op disk die er vanuit gaan dat timestamp '0' overeenkomt met 1970? Als je het unix timestamp '0' dus zou verzetten naar 2000, dan krijg je een enorme bende.

Vooral niet doen dus.

Het alternatief is anno 2009 vele malen logischer, omdat we nu toch over aan het gaan zijn naar processoren en besturingssystemen die van nature 64-bit zijn. De kosten van de opslag zijn ook niet meer relevant, dus geen lapmiddelen gebruiken en al helemaal geen lapmiddelen die problemen met bestaande implementaties/gebruiken geven.

Je zou de tijd nog als unsigned int kunnen behandelen - zodat je weer 65 jaar reserve krijgt, maar ook dat is niet logisch. Hooguit in het gebruik in binaire bestandsformaten (en dan alleen bij hoge uitzondering en alleen als je zeker weet dat je niets voor 1970 wilt kunnen aanduiden...)

[Dr. Horrible]

Licht het aan mij of je kan je ook gewoon doorgaan met tellen maar dan in een 64 bits integer. Het nulpunt op 1970 houden dus.

[Verwijderd]

ze kunnen er ook gewoon een 64 bits integer van maken. Lost ook veel op.

[Chocola]

Dat gaat veel extra werk kosten, elke UNIX computer, veel Linux systemen e.d. om de zoveel jaar resetten? Betaal jij het?

De huidige 64-bit integer werkt prima en dat lost naar mijn idee veel meer op :-P. Maar als je het hebt over de sofware vanuit Linux zelf: Nogsteeds is de integer veranderen veel rendabeler.

[Reactie gewijzigd door Chocola op 22 juli 2024 15:39]

[IStealYourGun]

Veel software gebruikt 1-1-1970 als basis om de dag te van vandaag te berekenen. Als je dat opeens zou veranderen naar 2000 dan gaan al die datum 's niet meer kloppen. Het is makkelijker om de standaard integer op 64 bit te zetten.

Meeste professionele applicaties gaan er trouwens geen probleem mee hebben omdat die vaak de tijd opslaan in een database.

[ATS]

En in die database is het opgeslagen als iets anders dan een standaard 32-bits getal? Dáár ligt juist de kern van het probleem. Niet in (actuele) software: die kan je makkelijk aanpassen, maar in legacy applicaties en bestandsformaten.

[deadinspace]

Uit het artikel:

Het 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.

Nee, Unix time wordt vastgelegd in een integer van een door de implementatie te kiezen grootte. Op 32-bit Unices is dat inderdaad vaak een 32-bit integer, maar dat hoeft niet.

Op 64-bit GNU/Linux is het bijvoorbeeld gewoon 64 bit:

$ uname -om
x86_64 GNU/Linux
$ cat time_t.c
#include <time.h>
#include <stdio.h>

int main( int argc, char **argv )
{
printf( "%li bits in time_t.\n", sizeof( time_t ) * 8 );
return 0;
}
$ ./time_t
64 bits in time_t.

Ook 64-bit Solaris heeft 64-bit Unix time als ik me niet vergis. Ik vermoed eigenlijk dat de meeste 64-bit Unices dat hebben, het is een vrij logische keuze.

Inmiddels wordt er al hard gewerkt aan een 64bit-methode voor onder andere Linux-systemen.

Zoals ik hierboven heb laten zien is dat er dus al

[Dreamvoid]

Hoe zit dat dan bij OS X met zijn 32 bit kernel?

[Verwijderd]

lapwing:~ brzboy$ uname -a
Darwin lapwing.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386

lapwing:~ brzboy$ cc time_t.c -o time_t
lapwing:~ brzboy$ ./time_t
32 bits in time_t.

lapwing:~ brzboy$ cc -m64 time_t.c -o time_t
lapwing:~ brzboy$ ./time_t
64 bits in time_t.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:39]

[Paridaen]

Op OSX kan je ook voor meerdere architecturen tegelijk compileren:

$ gcc -arch ppc -arch i386 -arch ppc64 -arch x86_64 time_t.c -o time_t
$ file time_t
time_t: Mach-O universal binary with 4 architectures
time_t (for architecture ppc7400): Mach-O executable ppc
time_t (for architecture i386): Mach-O executable i386
time_t (for architecture ppc64): Mach-O 64-bit executable ppc64
time_t (for architecture x86_64): Mach-O 64-bit executable x86_64

$ ./time_t
64 bits in time_t.

[Paridaen]

Op Solaris waar de kernel altijd 64-bit is wordt een source file default altijd op 32-bits gecompileerd. Dus:

% gcc time_t.c -o time_t
% file time_t
time_t: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped, no debugging information available
% ./time_t
32 bits in time_t.

Om een 64-bits executable te krijgen moet je dit doen:

gcc -m64 time_t.c -o time_t
% file time_t
time_t: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped, no debugging information available
% ./time_t
64 bits in time_t.

Dus de Solaris kernel zal geen last hebben, echter 32-bits applicaties kunnen wel problemen ondervinden

[awulms]

> date -d@4815162332
ma aug 3 03:05:32 CEST 2122
> uname -a
Linux 2.6.27.7-9-default #1 SMP 2008-12-04 18:10:04 +0100 x86_64 x86_64 x86_64 GNU/Linux

Wel op een 64-bits architectuur

[angelina]

Met 64 bits integer bestrijk je 9.223.372.036.854.775.807 seconden (2^63-1). Dat is ongeveer 292.269.422.665 jaar. Inderdaad voorlopig voldoende, lijkt mij.

[Verwijderd]

Dat dachten al die FORTRAN en COBOL programmeurs ook. "Ach, twee cijfers voor het jaartal, dan zitten we tot 2000 goed. Da's voorlopig wel voldoende."

Ik ben ineens wel benieuwd waar ze over 292.269.422.665 jaar nog FORTRAN programmeurs vandaan gaan halen.

[hackerhater]

Ik denk dat we tegen die tijd wel een ander probleem hebben
*denkt aan de zon die dan ongeveer opgebrand is*

[Verwijderd]

Geloof me, daar heb je méér dan genoeg aan... We hebben het hier over 292^9 jaar. De Zon zou ~4,57^9 jaar bestaan. Wanneer hij ongeveer na 10^9 jaar in een Rode Reus veranderd... En zachtjes uitdooft tot een Witte Dwerg. Dus die 292^9 jaar komt er nooit in de buurt.


OnTopic:
Wel leuk dat sommige mensen zich hiermee bezig houden, ik zelf heb er NOOIT aan gedacht. Misschien dat ik vandaag wel een borreltje neem in de naam van Unix en de Open Source community.

Bron: Wikipedia en Wikipedia

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:39]

[YopY]

xD, ook precies op die tijd gepost natuurlijk!

[GekkePrutser]

Ja, het was alleen wel leuk geweest om het even van tevoren te weten

[Noxious]

Een beetje nerd wist dit natuurlijk al dagen/maanden van te voren

[DeTeraarist]

sinds 1 januari 1970

[Zeror]

Een beetje tweaker heeft het topic, dat kort na opening gesloten werd, op het forum voorbij zien komen waardoor ie het wist

[Erkens]

Daar hebben we natuurlijk automagisch functies voor

[TERW_DAN]

pfff, niet een FPposter die met z'n vinger boven de send toets zit om het te versturen
Valt me eerlijk gezegd wel een beetje tegen

[Zeror]

Je hebt de database aangepast met dit speciale tijdstip

[Weiman]

Het Linux alternatief voor Valentijnsdag?

[AlexanderB]

ja
hebben wij ook nog wat om blij om te zijn