---

Jeg har set på
http://www.sslug.dk/adict/mgroup.php?organizer=SSLUG


at


perl -e 'print scalar(gmtime(2147483647))' - d. 19/1 2038 kl. 03:14 løber
Linux' ur over og alt bliver nulstillet...


Er der nogen som kan forklare nærmere ?

---

"Christian Thorsen" <nospam@hotmail.com> writes:

> perl -e 'print scalar(gmtime(2147483647))' - d. 19/1 2038 kl. 03:14 løber
> Linux' ur over og alt bliver nulstillet...
>
>
> Er der nogen som kan forklare nærmere ?

Det er en 31 bit værdi, med antal sekunder siden 1/1 1970.

Når man når dertil, løber tælleværket over og - ligesom i
speedometeret der går fra 99999 til 00000 - går tilbage til nul.

Løsningen er at skifte fra en 32 bit til en 64 bit tæller.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

"Christian Thorsen" <nospam@hotmail.com> writes:

> perl -e 'print scalar(gmtime(2147483647))' - d. 19/1 2038 kl. 03:14 løber
> Linux' ur over og alt bliver nulstillet...

> Er der nogen som kan forklare nærmere ?

Under Unix bliver alle klokkeslet gemt som et antal sekunder siden
1. januar 1970 klokken 00:00. Disse klokkeslet bliver sædvanligvis
gemt som tal med fortegn.

På 32bit-platforme (altså blandt andet i386) er det største tal der så
bruges 2^31-1, hvilket er 2147483647. Og netop i løbet af natten til
19. januar 2038 er det 2147483647 sekunder siden at 1970 begyndte.

64bit-platforme har ikke noget problem og de fleste applikationer
samt kernen burde kunne overleve i 68 år yderligere ved at opfatte
tidsstempler som værende uden fortegn. Det kræver bare en
genoversættelse af hele systemet.

Det er ikke noget specielt for linux. Andre 32bit-unixer har samme
problem.


Men til den tid bruger vi vel alle sammen 64bit og jeg er alligevel
ved at gå på pension.

--
Peter Makholm | I have no caps-lock but I must scream...
peter@makholm.net | -- Greg
http://hacking.dk |

---

In article <87k7jn2h94.fsf@xyzzy.adsl.dk>, Peter Makholm wrote:

>
> Men til den tid bruger vi vel alle sammen 64bit og jeg er alligevel
> ved at gå på pension.
>

Eller måske 128 bit, ingen ved hvad fremtiden bringer.

--
Med venlig hilsen
Bo Simonsen

---

Den 09 Nov 2002 12:29:56 GMT skrev Bo Simonsen:
>In article <87k7jn2h94.fsf@xyzzy.adsl.dk>, Peter Makholm wrote:
>
>>
>> Men til den tid bruger vi vel alle sammen 64bit og jeg er alligevel
>> ved at gå på pension.
>>
>
>Eller måske 128 bit, ingen ved hvad fremtiden bringer.

Nej, men hvis vi skal vente på Intel, så går der meget lang tid. Hvor
lang tid er det siden at resten af computer-verdenen gik over til
64-bit? Og hvornår går Intel seriøst over til 64-bit?

Første gang jeg legede med en 64-bit maskine, var dengang en 486 med
66MHz var vildt hurtig...

Mvh
Kent
--
Desuden kan jeg ikke se nogen grund til at springe over hvor gærdet er
lavest, når man kan vente på at det alligevel bliver revet ned fordi
der skal bygges en omfartsvej...
- Claus Frørup og Asbjørn Christensen i dk.snak.

---

In article <aqj44r$q3j$3@sunsite.dk>, Kent Friis wrote:

> Nej, men hvis vi skal vente på Intel, så går der meget lang tid. Hvor
> lang tid er det siden at resten af computer-verdenen gik over til
> 64-bit? Og hvornår går Intel seriøst over til 64-bit?

Der er langtid til år 2038, det skal nok nå at komme alt sammen hvis vi
forstiller os tiden ekspotiensielt aftager i forhold til skiftet med 16
bit > 32 bit.

--
Med venlig hilsen
Bo Simonsen

---

leeloo@phreaker.net (Kent Friis) writes:

> Nej, men hvis vi skal vente på Intel, så går der meget lang tid. Hvor
> lang tid er det siden at resten af computer-verdenen gik over til
> 64-bit? Og hvornår går Intel seriøst over til 64-bit?

---

Den 09 Nov 2002 16:54:12 +0100 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> Nej, men hvis vi skal vente på Intel, så går der meget lang tid. Hvor
>> lang tid er det siden at resten af computer-verdenen gik over til
>> 64-bit? Og hvornår går Intel seriøst over til 64-bit?
>
>Du blander hardware sammen med software API'er.

Teknisk set korrekt. Men 128 bit datoer bliver ikke relevant før om
584 milliarder år, og derfor ville det ikke være relevant at bruge
128bit til datoer, medmindre CPU'en er optimeret til at håndtere
128bit.

Mvh
Kent
--
You haven't seen _multitasking_ until you've seen Doom and
Quake run side by side

---

leeloo@phreaker.net (Kent Friis) writes:

> Teknisk set korrekt. Men 128 bit datoer bliver ikke relevant før om
> 584 milliarder år, og derfor ville det ikke være relevant at bruge
> 128bit til datoer, medmindre CPU'en er optimeret til at håndtere
> 128bit.

---

Den 09 Nov 2002 22:59:19 +0100 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> Teknisk set korrekt. Men 128 bit datoer bliver ikke relevant før om
>> 584 milliarder år, og derfor ville det ikke være relevant at bruge
>> 128bit til datoer, medmindre CPU'en er optimeret til at håndtere
>> 128bit.
>
>Det er en definitionssag. Jeg har brugt 16 bit heltal på 8-bit CPU'er,
>og 32 bit heltal på 16-bits CPU'er (som troede de var 32 bits).

Det kan man sagtens, men det gør man kun hvis man har brug for 16 bit.
Ikke for at beregne 2+2.

Og ligeledes bruger man kun 128bit datoer på en 64bit CPU, hvis man
har brug for datoer mere end 584 mia. år ude i fremtiden.

>Det er præcis så relevant som standarden siger det er.

Hvilken standard?

Mvh
Kent
--
"A computer is a state machine.
Threads are for people who can't program state machines."
- Alan Cox

---

leeloo@phreaker.net (Kent Friis) writes:

> >Det er en definitionssag. Jeg har brugt 16 bit heltal på 8-bit CPU'er,
> >og 32 bit heltal på 16-bits CPU'er (som troede de var 32 bits).
>
> Det kan man sagtens, men det gør man kun hvis man har brug for 16 bit.
> Ikke for at beregne 2+2.

Joda. Hvis det ikke vides at tallene er saa smaa.

>
> Og ligeledes bruger man kun 128bit datoer på en 64bit CPU, hvis man
> har brug for datoer mere end 584 mia. år ude i fremtiden.
>
> >Det er præcis så relevant som standarden siger det er.
>
> Hvilken standard?

---

Den 10 Nov 2002 00:39:49 +0100 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> >Det er en definitionssag. Jeg har brugt 16 bit heltal på 8-bit CPU'er,
>> >og 32 bit heltal på 16-bits CPU'er (som troede de var 32 bits).
>>
>> Det kan man sagtens, men det gør man kun hvis man har brug for 16 bit.
>> Ikke for at beregne 2+2.
>
>Joda. Hvis det ikke vides at tallene er saa smaa.

Hvis man ikke har brug for 16 bit, så er tallene så små.

>> Og ligeledes bruger man kun 128bit datoer på en 64bit CPU, hvis man
>> har brug for datoer mere end 584 mia. år ude i fremtiden.
>>
>> >Det er præcis så relevant som standarden siger det er.
>>
>> Hvilken standard?
>
>Den for API'et man bruger. I dette tilfaelde runtimebiblioteket.

Men det giver stadig ikke nogen grund til at ændre runtimebiblioteket
til 128-bit.

Mvh
Kent
--
"Handlingen blev afbrudt pga. computerens begrænsede effekt"
- Windows NT på en Pentium III 550 MHz

---

leeloo@phreaker.net (Kent Friis) writes:

> Hvis man ikke har brug for 16 bit, så er tallene så små.

CPU'en ved det ikke. Det er op til designeren af koden.

> >Den for API'et man bruger. I dette tilfaelde runtimebiblioteket.
>
> Men det giver stadig ikke nogen grund til at ændre runtimebiblioteket
> til 128-bit.

---

Bo Simonsen <bo@geekworld.dk> writes:

> Der er langtid til år 2038, det skal nok nå at komme alt sammen hvis vi
> forstiller os tiden ekspotiensielt aftager i forhold til skiftet med 16
> bit > 32 bit.

Det tror jeg ikke er en antagelse der er belæg for.

--
Peter Makholm | Sit back and watch the messages. This is actually
peter@makholm.net | more important than one might think as there is a
http://hacking.dk | bug in GNU Mach whereby hitting a key during the
| boot process causes the kernel to panic
| -- GNU Hurd Installation Guide

---

Hej.


"Peter Makholm" <peter@makholm.net> wrote in message
news:87k7jn2h94.fsf@xyzzy.adsl.dk...
> "Christian Thorsen" <nospam@hotmail.com> writes:
>
> > perl -e 'print scalar(gmtime(2147483647))' - d. 19/1 2038 kl. 03:14
løber
> > Linux' ur over og alt bliver nulstillet...
>
> > Er der nogen som kan forklare nærmere ?
>
> Under Unix bliver alle klokkeslet gemt som et antal sekunder siden
> 1. januar 1970 klokken 00:00. Disse klokkeslet bliver sædvanligvis
> gemt som tal med fortegn.
>
> På 32bit-platforme (altså blandt andet i386) er det største tal der så
> bruges 2^31-1, hvilket er 2147483647. Og netop i løbet af natten til
> 19. januar 2038 er det 2147483647 sekunder siden at 1970 begyndte.

Jeg mener faktisk, at vi allerede er ovre i unsigned, og det er den unsigned
tid, der udløber. Det skal nok blive ordnet inden da, for det er samme tid,
der bruges i Time-servere, som igen henter tid fra GPS-sattelitterne, der
får deres tid fra indbyggede atomure.

--

Med venlig hilsen/Best regards
Stig Johansen
Stig.Johansen@udvikling.it.dk
(remove dot dk)

---

"Stig Johansen" <stig.johansen@udvikling.it> writes:

> Jeg mener faktisk, at vi allerede er ovre i unsigned, og det er den unsigned
> tid, der udløber. Det skal nok blive ordnet inden da, for det er samme tid,
> der bruges i Time-servere, som igen henter tid fra GPS-sattelitterne, der
> får deres tid fra indbyggede atomure.

Det er da kun et problem på Unixplatforme. Windows bruger en anden
tidsregning.

Det bliver ikke rart hvis der kommer vild panik i Unixlejren op til,
hvor Windowsfolkene bare læner sig tilbage og lægger kabale.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Thorbjoern Ravn Andersen skrev den Sunday 10 November 2002 08:28 i
dk.edb.system.unix:


>> Jeg mener faktisk, at vi allerede er ovre i unsigned, og det er den
>> unsigned tid, der udløber. Det skal nok blive ordnet inden da, for det er
>> samme tid, der bruges i Time-servere, som igen henter tid fra
>> GPS-sattelitterne, der får deres tid fra indbyggede atomure.
> Det er da kun et problem på Unixplatforme. Windows bruger en anden
> tidsregning.
> Det bliver ikke rart hvis der kommer vild panik i Unixlejren op til,
> hvor Windowsfolkene bare læner sig tilbage og lægger kabale.

Det er da det der sker når der er flere uafhænige systemmer der har hver
deres begransninger. Dem der bruger de systemmer der ikke har en konkret
begransning, læner sig tilbage og spiller videre, mens dem der har
problemmet må få løst problemmet.
Hvem der har, og hvem der ikke har skifter så fra tid til anden,,,

--
Med venlig hilsen

Ivar Madsen

---

Thorbjoern Ravn Andersen <nospam0000@unixsnedkeren.dk> wrote:

>> Jeg mener faktisk, at vi allerede er ovre i unsigned, og det er den unsigned
>> tid, der udløber. Det skal nok blive ordnet inden da, for det er samme tid,
>> der bruges i Time-servere, som igen henter tid fra GPS-sattelitterne, der
>> får deres tid fra indbyggede atomure.

> Det er da kun et problem på Unixplatforme. Windows bruger en anden
> tidsregning.

> Det bliver ikke rart hvis der kommer vild panik i Unixlejren op til,
> hvor Windowsfolkene bare læner sig tilbage og lægger kabale.

Windows har også disse "unix" tider diverse steder i applikationer.
Så dele af windows regner tid på en måde og, andre dele (applikationer
og visse API) vil have samme fejl (specielt det der relaterer til
internet og evt. POSIX kompatibilitet)

Så der bliver nok problemer også med Windows, men mon
ikke de max 5 års support på windows produkter løser dette,
idet der simpelthen ikke vil være gamle windows versioner
kørende til den tid ?


--
Frank Damgaard |

---

"Stig Johansen" <stig.johansen@udvikling.it> writes:

> Jeg mener faktisk, at vi allerede er ovre i unsigned, og det er den
> unsigned tid, der udløber.

Det er det ikke. Vi har faktisk ikke engang taget hul på bit 30 endnu.

Det er ikke så længe siden, at vi rundede præcis én millard sekunder
siden 1. januar 1970. Det blev faktisk fejret af unix-nørder på samme
måde som Y2K.

Det skete herhjemme:

$ perl -e 'print scalar localtime 10**9'
Sun Sep 9 03:46:40 2001

Vi begynder at bruge bit 30 på følgende tidspunkt:

$ perl -e 'print scalar localtime 2**30'
Sat Jan 10 14:37:04 2004

Og endelig løber vi som allerede nævnt ind i bit 31 på følgende tidspunkt:

$ perl -e 'print scalar localtime 2**31-1'
Tue Jan 19 04:14:07 2038

--
-- Torben.

---

Den Sun, 10 Nov 2002 05:32:44 +0100 skrev Stig Johansen:
>Hej.
>
>
>"Peter Makholm" <peter@makholm.net> wrote in message
>news:87k7jn2h94.fsf@xyzzy.adsl.dk...
>> "Christian Thorsen" <nospam@hotmail.com> writes:
>>
>> > perl -e 'print scalar(gmtime(2147483647))' - d. 19/1 2038 kl. 03:14
>løber
>> > Linux' ur over og alt bliver nulstillet...
>>
>> > Er der nogen som kan forklare nærmere ?
>>
>> Under Unix bliver alle klokkeslet gemt som et antal sekunder siden
>> 1. januar 1970 klokken 00:00. Disse klokkeslet bliver sædvanligvis
>> gemt som tal med fortegn.
>>
>> På 32bit-platforme (altså blandt andet i386) er det største tal der så
>> bruges 2^31-1, hvilket er 2147483647. Og netop i løbet af natten til
>> 19. januar 2038 er det 2147483647 sekunder siden at 1970 begyndte.
>
>Jeg mener faktisk, at vi allerede er ovre i unsigned, og det er den unsigned
>tid, der udløber.

kfr:kfr$ dc
2 31 ^ 60 / 60 / 24 / 365.25 / 1970 + p
2038
2 32 ^ 60 / 60 / 24 / 365.25 / 1970 + p
2106

Med 31 bit (signed) får vi overflow i 2038. Med 32 bit (unsigned) er det
først i 2106.

Mvh
Kent
--
"Intelligence is the ability to avoid doing work, yet get the work done"
- Linus Torvalds

---

leeloo@phreaker.net (Kent Friis) writes:

> Med 31 bit (signed) får vi overflow i 2038. Med 32 bit (unsigned) er det
> først i 2106.

---

Hej.


"Kent Friis" <leeloo@phreaker.net> wrote in message
news:aql6t4$77s$5@sunsite.dk...
> Den Sun, 10 Nov 2002 05:32:44 +0100 skrev Stig Johansen:
> >Hej.
> >
> >
> >"Peter Makholm" <peter@makholm.net> wrote in message
> >news:87k7jn2h94.fsf@xyzzy.adsl.dk...
> >> "Christian Thorsen" <nospam@hotmail.com> writes:
> >>
> >> > perl -e 'print scalar(gmtime(2147483647))' - d. 19/1 2038 kl. 03:14
> >løber
> >> > Linux' ur over og alt bliver nulstillet...
> >>
> >> > Er der nogen som kan forklare nærmere ?
> >>
> >> Under Unix bliver alle klokkeslet gemt som et antal sekunder siden
> >> 1. januar 1970 klokken 00:00. Disse klokkeslet bliver sædvanligvis
> >> gemt som tal med fortegn.
> >>
> >> På 32bit-platforme (altså blandt andet i386) er det største tal der så
> >> bruges 2^31-1, hvilket er 2147483647. Og netop i løbet af natten til
> >> 19. januar 2038 er det 2147483647 sekunder siden at 1970 begyndte.
> >
> >Jeg mener faktisk, at vi allerede er ovre i unsigned, og det er den
unsigned
> >tid, der udløber.
>
> kfr:kfr$ dc
> 2 31 ^ 60 / 60 / 24 / 365.25 / 1970 + p
> 2038
> 2 32 ^ 60 / 60 / 24 / 365.25 / 1970 + p
> 2106
>
> Med 31 bit (signed) får vi overflow i 2038. Med 32 bit (unsigned) er det
> først i 2106.

Se:
http://www.faqs.org/rfcs/rfc868.html
nederst.

--

Med venlig hilsen/Best regards
Stig Johansen
Stig.Johansen@udvikling.it.dk
(remove dot dk)

---

"Stig Johansen" <stig.johansen@udvikling.it> writes:

>> På 32bit-platforme (altså blandt andet i386) er det største tal der så
>> bruges 2^31-1, hvilket er 2147483647. Og netop i løbet af natten til
>> 19. januar 2038 er det 2147483647 sekunder siden at 1970 begyndte.
>
> Jeg mener faktisk, at vi allerede er ovre i unsigned, og det er den unsigned
> tid, der udløber.

Nope. 2**31-1 er netop det største signed tal der kan angives i en
32bit-tæller.

Jeg fandt lige en Alpha der kører Linux:

brother@tyge$ perl -e ' print join "\n", map { scalar(gmtime $_) } 0, 2**31-1, 2**32-1, 2**55, 2**63-1, 2**64-1'
Thu Jan 1 00:00:00 1970
Tue Jan 19 03:14:07 2038
Sun Feb 7 06:28:15 2106
Sun Jun 13 06:26:08 1141709097

Wed Dec 31 23:59:59 1969brother@tyge$

Hmmmm, underligt hvorfor intet resultat for 2**63-1.

[leget lidt]

Hmmmm, årstallet bliver gemt som et 32bits tal med fortegn.

brother@tyge$ perl -e ' print scalar(gmtime 0x00f0c2ab7c54a97f), "\n"'
Wed Dec 31 23:59:59 -2147481749
brother@tyge$ perl -e ' print scalar(gmtime 0x00f0c2ab7c54a980), "\n"'

brother@tyge$ perl -e ' print scalar(gmtime 0x00f0c29d868bfd7f), "\n"'
Tue Dec 31 23:59:59 2147483647
brother@tyge$ perl -e ' print scalar(gmtime 0x00f0c29d868bfd7f+1), "\n"'
Wed Jan 1 00:00:00 -2147483648
brother@tyge$

Jeg tror ikke helt jeg forstår det her.

--
Peter Makholm | First you fall in love with Antarctica, and then it
peter@makholm.net | breaks you heart
http://hacking.dk | -- Antarctica

---

Peter Makholm wrote:

> "Christian Thorsen" <nospam@hotmail.com> writes:
>
>> perl -e 'print scalar(gmtime(2147483647))' - d. 19/1 2038 kl. 03:14
>> løber Linux' ur over og alt bliver nulstillet...
>
>> Er der nogen som kan forklare nærmere ?
>
> Under Unix bliver alle klokkeslet gemt som et antal sekunder siden
> 1. januar 1970 klokken 00:00. Disse klokkeslet bliver sædvanligvis
> gemt som tal med fortegn.
>
> På 32bit-platforme (altså blandt andet i386) er det største tal der
> så bruges 2^31-1, hvilket er 2147483647. Og netop i løbet af natten
> til 19. januar 2038 er det 2147483647 sekunder siden at 1970
> begyndte.

> Men til den tid bruger vi vel alle sammen 64bit og jeg er alligevel
> ved at gå på pension.

Ja vi gør det er ikke pc'erne der giver de store problemer men alle
de embedded systemer der er i alt mugligt ikke computer relateret
hardware.

tag for eks københavns nye metro designet til at køre i 100år er du
100% sikker på at de toge der er blevet leveret nu ikke er i drift et
eller andet sted i 2038 osv.
Det der med toge er heller ikke noget dørlig eksempel eftersom der 1
janaur 2000 ikke kørte hurtig toge i norge grundet år 2000 problemet.

Kraftværker og den slags har en ligndende opdaterings cyklus og det
samme gælder for alle de plc'er der står rund omkring på fabrikkerne.
Så et realistisk scenario er 19. januar 2038 vøgner du ikke op til
aftalt tid da stømmen er gået du kan ikke komme på arbejede, togene
kører ikke og den maskine du passer er gået død.
Men din pc har det fint og banken kan sagtens finde ud af at du har
gæld osv.

Hvis vi ikke mget snart begydet at tagehøjde for det har vi baladen
den 19 Janaur 2038.

--
Daniel Udsen
"It runs like _x, where _x is something unsavory"
-- Prof. Romas Aleliunas, CS 435

---

dudsen <dudsen@gjk.dk> writes:

> tag for eks københavns nye metro designet til at køre i 100år er du
> 100% sikker på at de toge der er blevet leveret nu ikke er i drift et
> eller andet sted i 2038 osv.

Mig? Nejda. Hvem siger at de computere er Unixbaserede?

> Hvis vi ikke mget snart begydet at tagehøjde for det har vi baladen
> den 19 Janaur 2038.

Man kunne forvente at det kom i en passende 64 bit revision af diverse
distributioner.

Mængden af 32-bit pentiumsystemer må forventes at være aftagende i
løbet af 30 år.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Thorbjoern Ravn Andersen wrote:

> dudsen <dudsen@gjk.dk> writes:
>
>> tag for eks københavns nye metro designet til at køre i 100år er du
>> 100% sikker på at de toge der er blevet leveret nu ikke er i drift
>> et eller andet sted i 2038 osv.
>
> Mig? Nejda. Hvem siger at de computere er Unixbaserede?

Igen men linux er ved at have en betydelig andel af markedet for
ebbedet systemer og hvem siger at der ikke findes realtid o/s'er der
regner tiden ud i sekunder fra epoch.

>> Hvis vi ikke mget snart begydet at tagehøjde for det har vi baladen
>> den 19 Janaur 2038.
>
> Man kunne forvente at det kom i en passende 64 bit revision af
> diverse distributioner.

Hvis ikke de versioner der retter sig imod ebedded systems kommer i
en version der tager hånd om 2038 problemet meget snart kommer vi til
at løbe om kap med tiden for at finde alle de steder der sidder en
32bit chip.
Og problemet er ikke løst ved en nu distribution i 2030 da du ikke
opdatere softwaren i dit komfur da du højst sandsynligt ikke er klar
over at det overhovedet bruger software.
Og efter ca 2 år på markedet er fejlne fundet og behøvet for at
tilføje funktionalitet er meget lille.

> Mængden af 32-bit pentiumsystemer må forventes at være aftagende i
> løbet af 30 år.

du finder 16 og enda 8bit systemer på kritiske steder den dag idag.
Prblmet er ikke pc'er eller serverne men alt det isenkram der ikke
nårmalt forbindes med computere.

--
Daniel Udsen
Greatness is a transitory experience. It is never consistent.

---

dudsen <dudsen@gjk.dk> writes:

> Og problemet er ikke løst ved en nu distribution i 2030 da du ikke
> opdatere softwaren i dit komfur da du højst sandsynligt ikke er klar
> over at det overhovedet bruger software.

Sædvanligvis finder du vel tidsforløb ved at trække to tidsværdier fra
hinanden, og her findes problemet ikke.

Jeg ved ikke meget om embeddede systemer, men jeg kan da godt se
problematikken.

> du finder 16 og enda 8bit systemer på kritiske steder den dag idag.
> Prblmet er ikke pc'er eller serverne men alt det isenkram der ikke
> nårmalt forbindes med computere.

Næh, men hvor mange af dem lider af et problem i denne sammenhæng?
Det er jo en tæller der løber over, uden spring i værdierne (som det
var ved år2000problemet). Forskelle vil derfor stadig være gyldige.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

"Stig Johansen" <stig.johansen@udvikling.it> writes:

> Hej.

Prøv at klippe det væk du ikke direkte kommenterer.

>> Med 31 bit (signed) får vi overflow i 2038. Med 32 bit (unsigned) er det
>> først i 2106.

> http://www.faqs.org/rfcs/rfc868.html

RFC868 beskriver en helt anden situation da der her tælles fra
1. januar 1900 og ikke 1. januar 1970.

Er det iøvrigt kun mig der har svært ved at se hvordan de både kan
angive 2.629.584.000 og -1.297.728.000 i et 32bit tal. Jeg får
lg2(2629584000)=31.29. Altså skal der mere end 31 bit til at angive
det.

--
Peter Makholm | We constantly have to keep in mind why natural
peter@makholm.net | languages are good at what they're good at. And to
http://hacking.dk | never forget that Perl is a human language first,
| and a computer language second

---

Peter Makholm (peter@makholm.net) wrote:
>
> RFC868 beskriver en helt anden situation da der her tælles fra
> 1. januar 1900 og ikke 1. januar 1970.
>
> Er det iøvrigt kun mig der har svært ved at se hvordan de både kan
> angive 2.629.584.000 og -1.297.728.000 i et 32bit tal. Jeg får
> lg2(2629584000)=31.29. Altså skal der mere end 31 bit til at angive
> det.

Mit gæt:

De beskriver en protokol hvormed en server kan fortælle hvad klokken er, så
det er sjældent at den har brug for at sige et tidspunkt før år 1900, så kan
man lige så godt bruge den bit mere til fremtidssikring.

Den første mærkelige ting er så at de har valgt at medtage et eksempel som
protokollen ikke kan angive.

Den anden mærkelige ting er at de i 1983 har lavet såden en protokol, og så
har taget udgangspunkt i år 1900, det virker ret tåbeligt.


Mvh.

Dennis Jørgensen

---

Peter Makholm <peter@makholm.net> writes:

> Er det iøvrigt kun mig der har svært ved at se hvordan de både kan
> angive 2.629.584.000 og -1.297.728.000 i et 32bit tal. Jeg får
> lg2(2629584000)=31.29. Altså skal der mere end 31 bit til at angive
> det.

Jeg kan gøre det i én bit, jeg kan så ikke repræsentere andre tal, men
det sagde du heller ikke jeg skulle.

Eftersom 2.629.584.000-(-1.297.728.000)=3.927.312.000<2^32 kræver det
bare en repræsentation hvor man ikke kan repræsenteret lige så mange
negative tal som positive. Nej, det er ikke sandsynligt at der er nogen
der rent faktisk gør det.

..Henrik

--
IQ er et tal med lige så god anvendelseværdi som BogoMIPS.
-- citat Peter Makholm

---

Hej.
"Peter Makholm" <peter@makholm.net> skrev i en meddelelse
news:87el9sh9k7.fsf@xyzzy.adsl.dk...
> "Stig Johansen" <stig.johansen@udvikling.it> writes:
>
> > Hej.
>
> Prøv at klippe det væk du ikke direkte kommenterer.

Undskyld, jeg var nopk ikke helt vågen.

> RFC868 beskriver en helt anden situation da der her tælles fra
> 1. januar 1900 og ikke 1. januar 1970.

Ja, det var for at henlede opmærksomheden på, at 'internet tiden' bryder
sammen før 2038. Den løsning, der kommer ud af det skal nok blive
implementeret på diverse OS'er.

mvh
Stig.

---

"Stig Johansen" <a@b.c> writes:

> Hej.
> "Peter Makholm" <peter@makholm.net> skrev i en meddelelse
> news:87el9sh9k7.fsf@xyzzy.adsl.dk...
>
> > RFC868 beskriver en helt anden situation da der her tælles fra
> > 1. januar 1900 og ikke 1. januar 1970.
>
> Ja, det var for at henlede opmærksomheden på, at 'internet tiden' bryder
> sammen før 2038. Den løsning, der kommer ud af det skal nok blive
> implementeret på diverse OS'er.

RFC868 er en meget gammel standard, som vist ikke bruges til ret meget
i praksis i dag. I dag bruger man NTP, som ifølge RFC2030 vil fungere
indtil en gang i år 2104.

--
-- Torben.

---

Peter Makholm <peter@makholm.net> writes:

> Er det iøvrigt kun mig der har svært ved at se hvordan de både kan
> angive 2.629.584.000 og -1.297.728.000 i et 32bit tal. Jeg får
> lg2(2629584000)=31.29. Altså skal der mere end 31 bit til at angive
> det.

Det må være en fejl med det negative eksempel, for de skriver at deres
32-bit tal kan holde til år 2036.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-'`' -. ;-;;,_ | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Phone: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.