Ubuntu Guide Lommebog

[Jeg]

Ja, jeg regner alligevel med at være drukket fra sans og samling på det tidspunkt..

[Don S]

Gad vide om det kommer i nyhederne. Om noget, så kunne det i almindelige menneskers hoveder, være lige så farligt som 2000-skiftet.

[laoshi]

så kunne det i almindelige menneskers hoveder, være lige så farligt som 2000-skiftet.

Og det er du sikker på at det ikke er? Uha, uha...

[soundpartner]

Gad vide om det kommer i nyhederne. Om noget, så kunne det i almindelige menneskers hoveder, være lige så farligt som 2000-skiftet.

tjaaa det kunne sgu da være sjovt at kave en præssemeddelelse samt et eller andet event. men det er jo lidt sent nu

[Jarlen]

Gad vide om det kommer i nyhederne. Om noget, så kunne det i almindelige menneskers hoveder, være lige så farligt som 2000-skiftet.

Det er nok nærmere når uret resetter

[thj01]

teknisk set er den jo ligegyldigt.

For den interessante "dato" ville være 0123456789

eller skulle det jo hedde : 12345678910

Den næste relevante dato burde jo være 123456789ABCDEF - men der går nok lige nogle år endnu

[Don S]

teknisk set er den jo ligegyldigt.

For den interessante "dato" ville være 0123456789

eller skulle det jo hedde : 12345678910

Den næste relevante dato burde jo være 123456789ABCDEF - men der går nok lige nogle år endnu

Hvorfor skrive unix timestamps som hex? Det er jo bare antallet af sekunder der har passeret siden 1970. Næh, man skal være bange, når den datatype som Unix timestampet er gemt som (32-bit integer) når sit maks:

Velkommen til 1901!

... Hvis man altså stadig bruger et 32-bit system til den tid.

[Jarlen]

teknisk set er den jo ligegyldigt.

For den interessante "dato" ville være 0123456789

eller skulle det jo hedde : 12345678910

Den næste relevante dato burde jo være 123456789ABCDEF - men der går nok lige nogle år endnu

Hvorfor skrive unix timestamps som hex? Det er jo bare antallet af sekunder der har passeret siden 1970. Næh, man skal være bange, når den datatype som Unix timestampet er gemt som (32-bit integer) når sit maks:

Velkommen til 1901!

... Hvis man altså stadig bruger et 32-bit system til den tid.

Lige præcis. Det store problem ville være at nå 9999(osv.) hvor uret restarter. Det kunne give problemer nogle steder hvis man ikke er forberedet

[thj01]

min pointe er nu bare at det ikke holder at sætte et 0 bagpå - fordi det tal - eller måske rettere begreb ligger før 1.

derfor er det kun talrækkerne

1
12
123
1234
12345
123456
1234567
12345678
123456789

Der er interessante i decimal systems sammenhænge

Den eneste måde man kan gøre andre talrækker interessante ud fra denne begtragtning er ved at kigge på andre base-systemer. Der er det Hexadecimale system det eneste der er interessant ud fra en computersammenhæng

[Jeg]

Det ser sjovt ud.. Er den længere end det?

[Don S]

min pointe er nu bare at det ikke holder at sætte et 0 bagpå - fordi det tal - eller måske rettere begreb ligger før 1.

derfor er det kun talrækkerne

1
12
123
1234
12345
123456
1234567
12345678
123456789

Der er interessante i decimal systems sammenhænge

Den eneste måde man kan gøre andre talrækker interessante ud fra denne begtragtning er ved at kigge på andre base-systemer. Der er det Hexadecimale system det eneste der er interessant ud fra en computersammenhæng

Problemet med 123456789ABCDEF er bare, at det langt overskrider de 32 bit...

Kode: Vælg alt

123456789ABCDEF (hex) = 81985529216486895 (decimal) 
(2^32)/2              = 2147483648                
(2^64)/2              = 9223372036854775808

Men ikke de 64 bit, så lidt interessant er det tidspunkt vel.

[Jarlen]

Det interessante/"skræmmende" er vel egentlig 2147483648 (2^31) hvor alle de systemer der behandler tallet som et signed 32-bit integer pludselig skifter til -2147483649, hvilke må siges at være en smule forkert set ud fra et tidsperspektiv.

[lath]

0x123456789ABCDEF er 81985529216486895 decimalt

2 tals logaritmen (log2) af 81985529216486895 er:
log2(81985529216486895) = ln(81985529216486895)/ln(2), hvor ln er den naturlige logaritme.
ln(81985529216486895)/ln(2) = 56,186218809,

dvs at 0x123456789ABCDEF mindst kræver 57 bits

Da jeg kører 64 bit Linux er det interessant om der i kernen stadig kun er 32 bit understøttelse af tidstælleren (som tæller i millisekunder siden 1. januar 1970[1] kl 0 (midnat)), og at der er en 64-bit wrappertype i libc, således at programmer kan programmeres med 64 bit, men i virkeligheden bruger en 32 bit tæller

eller

om der rent faktisk i kernen på 64 bit Linux er understøttelse af 64 bit tæller i tid.

Det er egentligt nemt at se, kig i i Linux kernens kildekode, men jeg har ikke tid pt. (jeg laver bachelor projekt).

/Lars

[1] sikker på at det er 1970, men det kan være fra en anden måde at tælle på. Links med hensyn til 190x, plz. Har dog ikke links til den med 1970, desværre.

[Don S]

0x123456789ABCDEF er 81985529216486895 decimalt

2 tals logaritmen (log2) af 81985529216486895 er:
log2(81985529216486895) = ln(81985529216486895)/ln(2), hvor ln er den naturlige logaritme.
ln(81985529216486895)/ln(2) = 56,186218809,

dvs at 0x123456789ABCDEF mindst kræver 57 bits

Da jeg kører 64 bit Linux er det interessant om der i kernen stadig kun er 32 bit understøttelse af tidstælleren (som tæller i millisekunder siden 1. januar 1970[1] kl 0 (midnat)), og at der er en 64-bit wrappertype i libc, således at programmer kan programmeres med 64 bit, men i virkeligheden bruger en 32 bit tæller

eller

om der rent faktisk i kernen på 64 bit Linux er understøttelse af 64 bit tæller i tid.

Det er egentligt nemt at se, kig i i Linux kernens kildekode, men jeg har ikke tid pt. (jeg laver bachelor projekt).

/Lars

[1] sikker på at det er 1970, men det kan være fra en anden måde at tælle på. Links med hensyn til 190x, plz. Har dog ikke links til den med 1970, desværre.

time_t (som variablen hedder) er i følge Wikipedia en 64 bit signed integer på 64 bit systemer. Men mange embedded systemer bruger i dag 32 bit, og de bliver måske ikke erstattet inden 2038.
http://en.wikipedia.org/wiki/2038_problem

[Jarlen]

Jeg kunne forestille mig at der var rigtig mange indlejrede systemer der kørte mindre end 32bit, gad vide hvordan det egentlig er implementeret der?