Pa mislim da ce da bude aktuelno 2037. Do tad i nije neki faktor :-). Mada, nece biti ni tad, posto ce do tad, sigurno, time_t postati bar 64bitni ili ce quantum computing zaziveti i rado cemo se setiti da je „danas eto trebalo da bude smak sveta“ :-)

Znaci do 2038 svi 32bitni programi ce morati biti portovani u 64bitne, to mi bas ne izgleda jeftino

To je za 30 godina... zadnjih 30 godina je IT napredovala od 8bitnih do 64bitnih procesora. I to je bila krivulja eksponencijalnog rasta. Mislis da ce 2038 biti ista 32bit compatible? Mozda elektricni sporet ili tako nesto..

Pa dobro, i toje potencijalni problem Tako 2038 sav pun poverenja stavis pile u rernu i ukljucis na 2 sata a vuruna sracuna da treba da je izgasi za 68 godina Ti se onda zablesavis kodirajuci svoju munjastu Nbitnu (N>1024) masinu i pile izgori, dodje zena i naljuti se i kaze "ovo je kap koja je prelila casu" i ostavi te pod stare dane.


Iskreno, slazem se i ja, ako neko 2038 jos uvek bude koristio 32-bitni unix timestamp taj i zasluzuje da mu se nesto desi tim povodom. Kad mi '99 nije bilo zao onih skrtica sto ih zadesila Y2K, necu se mnogo potresti zbog ovoga.

Moram malo da te razočaram, to koliko se bitova koristi za zapis nekog tipa podatka nema puno veze sa "bitnošću" procesora... Tj, taj datum se može zapisati sa 32 (33, 64, 567 itd) bita i na 8-bitnom i na 128-bitnom računaru.

Nije da nisi u pravu, ali ipak na 8-bitnim procesorima nisi imao ugrađene operacije nad 32-bitnim celim brojevima. Današnji procesori imaju podršku za 64-bitnu aritmetiku, pa su i tipovi u današnjim programskim jezicima u skladu sa tim. Za šire opsege moraš ili imati klasu biginteger (kao što je imaju neki PJ, a za druge postoje biblioteke) ili moraš da je doprogramiraš. Te klase svakako ne rade onoliko brzo kao hardverski podržani tipovi.

Stoga su i ovakvi tipovi, koji su zasnovani na celobrojnim tipovima, usklađeni sa tim.

Ja koliko znam, i u Javi i u C#-u integer je 32 bita, bez obzira na kom procesoru ga izvršavaš. Doduše, možda ti pod "današnjim" podrazumevaš druge jezike...

Ko da sam negde skoro citao da "upgrade" vise ne vazi automatski, tj da ce int i dalje ostati 32bit bez obzira na 64bit compiler, nisam siguran za C++ ali za C# je definitivno int zakljucan za System.Int32, tako da nista od automatske promocije u 64bita.

Ima tu i drugih problema, npr f-je koje parsiraju i generisu tekstualne reprezentacije time_t moraju takodje da se promene da uzmu u obzir nove opsege.

mali OT:

po Unix vremenu 1234567890 je Petak, 13 Februar 2009 23:31:30 GMT

jos malo do tada :)

Java i C# imaju 64-bitni celobrojni tip long.

http://leepoint.net/notes-java/data/basic_types/21integers.html
http://msdn.microsoft.com/en-us/library/ctetwysk(VS.80).aspx

U praktično svim savremenim C++ kompajlerima je int širine je 32 bita, kao i long, koji je sinonim za long int. short je sinonim za short int i ima širinu od 16 bita. Međutim, GNU C++ (uključujući i MinGW), kao i MS VC++ podržavaju tip long long, koji je sinonim za long long int i ima širinu od 64 bita.
Svi celobrojni tipovi (uključujući i char, mada neki tu trpaju i bool) su po difoltu označeni, a imaš mogućnost i da dodaš unsigned ako želiš neoznačen tip.

To sve stoji, samo sto sam ja, a ocigledno i jablan, skapirali da ti mislis da ce problem nestati sam od sebe tako sto ce int tip automatski otici na 64bita i da ce biti dovoljno samo ponovo prevesti biblioteke novim kompajlerom koji tretira int kao signed 64bit.

Nece nestati sam od sebe zbog cuvanja binarne kompatibilnosti sa 32-bitnim time_t tipom.

Jablan je govorio kako se ne bilokolkobitnom procesoru moze vreme predstaviti bilokolkobitnim tipom, sto jeste tacno, ali se zbog efikasnosti obicno vezuje za masinski podrzane celobrojne tipove.

Da je 2037. malo blize nego sto jeste, mislim da bi bio poprilican problem. Y2k je bio mahom "bazadzijski" problem - problem nije bio do "nativnog" pisanja datuma, vec pisanja u obliku decimalnih cifara, sto je tipicno za baze podataka a ne npr. za mikrokontrolere. Posto su oni koji koriste baze mahom taj problem sreli pre 2000., npr. kada je 1980. banka htela da nekom da stambeni kredit na 20 godina, to je najcesce moralo da se resava pre 2000.

Vidim dva problema ovde. Za pocetak, 2037. cemo biti mnogo vise kompjuerizovani nego sto smo bili 2000. pa ce broj aplikacija koje treba proveriti biti mnogo veci. Drugi problem je spomenuti problem pecenog pileta od 67godina, jer mi deluje da ce mnogi mikrokontroleri koji ce vredno da rade u automobilima, avionima i raznoj opremi i dalje da datum pisu u 2^n bitova; nadajmo se samo da n nece biti 32.