Dosažením jedné miliardy sekund se ale timestamp změní z devíticiferného čísla na deseticiferné. Systémům samotným to ještě vadit nebude, problémy ovšem mohou nastat u špatně napsaných aplikací, pokud používají pro práci s časem nevhodně dimenzované proměnné.
Já jsem si myslel, že lajdáci místo time_t používají int, ale že by někdo používal char[10], to mne ani ve snu nenapadlo. Ale je pravda, že včera jsem v nějakém vzorovém prográmku viděl počítání pořadového dne v roce tak, že autor použil strftime s formátem %j a na výsledek vypustil atoi. Takže takoví lidé možná opravdu existují.
ja myslim ale ze ani v tom roce 2038 to nebude problem
teda esli to chapu spravne tak staci predefinovat
typ time_t na neco vetsiho
treba na longlong, kterej uz je implementovanej
(nevim jak v unixech, ale v linuxu je)
nehlede na to ze uz asi fakt budem uplne nekde jinde :)))
To je hezká teorie, ale v praxi je spousta programů, kde autor místo time_t používá natvrdo int,
long nebo něco takového (taky jsem jich kdysi pár napsal, stydím se, už to víckrát neudělám). Pak je spousta dalších, kde autor sice použije time_t, ale vzápětí ho přiřadí do int. A další, subtilnější chyby: třeba pro zjištění rozdílu mezi dvěma okamžiky použije t2-t1, což bude v pořádku, pokud time_t bude int nebo 64-bitový integer, ale při jiné implementaci není použitelnost takové konstrukce zaručena.
Ono to nastava spis ve chvili, kdy to datum chceme rozumne vytisknout. Obvykle se pak musi prevest na retezec. (tedy pokud to tiskneme nejakou slozitejsi metodou nez printf).
To samozřejmě ano, ale jak často je potřeba tisknout datum (čas) v tomto formátu? Když už se tiskne, obvykle je to v nějakém tvaru čitelném pro člověka (třeba d.m.yyyy) a do něj se převádí buď přímo z time_t nebo ze struct tm.
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).
