problem 2000 i cd.

jak wiadomo w 2000r padło wiele programów, które były pisane na stare systemy win, czy dos.
problem polegał na tym, że programista zapisywał daty w postaci skróconej, żeby zaoszczędzić miejsce:
67 = 1967, 99 = 1999, czyli tylko ostatnie 2 cyfry;

a wtedy w 2000r to się przewinęło o 100 lat do tyłu: 2000 = 1900, 2005 = 1905;

ok.
a ja mam pytanie o innych ograniczeniach, które programiści zapewne nadal używali po 2000r.
np. gettime w c, czy delphi chyba podaje tylko 32 bity w sekundach, zatem to się znowu wyzeruje... chyba wkrótce - kiedy?

time = gettime();
i tu były liczone sekundy od 1970r,
rok ma 365 x 86400 = 31536000 sekund;

tradycyjny long ma 32 bity, limit 2^31, czyli: 2^31 / 31536000 = 68 lat

1970 + 68 = 2038

czyli te programy padną w 2038r, a nawet trochę wcześniej z uwagi na lata przestępne.

W związku z tym pytanie: jak się zabezpieczyć przed tą wpadką,
bez zwiększania rozmiaru danych: ten long = 32 bity ma pozostać?

Użycie 64 bitowej zmiennej czasowej zapewni działanie programowi do kresu naszej cywilizacji.

mowa o starych programach, a nie o nowoczesnych wynalazkach przygłupów z epoki bigdata.

Może pozostać 32 bity, ale zmienić signed na unsigned. Przesunie się tylko zakres dat, jakie można wyrazić, a i tak mało kto potrzebuje wyrazić daty starsze niż 1 stycznia 1970. Prosta rzecz, a odwlecze się problem o kolejne 68 lat, czyli kres nastąpi dopiero w okolicach roku 2100.

Law napisał(a):

mowa o starych programach, a nie o nowoczesnych wynalazkach przygłupów z epoki bigdata.

To musisz zapytać przygłupów sprzed 2000. Może się dowiesz czemu się nie zabezpieczyli.

Law napisał(a):

mowa o starych programach, a nie o nowoczesnych wynalazkach przygłupów z epoki bigdata.

Zakładam, że idea zrobienia tego porządnie, czyli wzięcia szerszego typu danych cię nie zadowala z jakiegoś powodu. Czyli mówimy zapewne o naprawieniu aplikacji sprzed kilkunastu lub kilkudziesięciu lat, która powinna działać jeszcze za 14 lat, a nie chcemy jej za bardzo modyfikować. Najprościej wydaje mi się, byłoby zmienić punkt odniesienia z 1970 na np. 2020. Ale wtedy tracisz możliwość zapisania przeszłych dat sprzed "punktu zero". No i raczej nie dogadasz się z systemem operacyjnym ani z żadnym innym systemem/programem na zewnątrz. Może to akceptowalne.

Law napisał(a):

jak wiadomo w 2000r padło wiele programów, które były pisane na stare systemy win, czy dos.

Ja się nie spotkałem. Ba, w latach 90-tych miałem datę przestawioną na 100 lat do przodu bo mój tata był paranoikiem i bał się wirusów które były nastawione na odpalenie w konkretny dzień a faktycznie takie wtedy istniały. Podejrzewam że bardziej chodzi o jakieś programy korzystające z baz danych i obliczanie różnić dat, zwykłe programy dla szarego użytkownika działały w porządku. Problemem też były inputy które miały dwie pozycje a wbudowane funkcje do tworzenia dat na bazie dwucyfrowych liczb niekoniecznie tworzyły dobrą datę.

1970 + 68 = 2038

czyli te programy padną w 2038r, a nawet trochę wcześniej z uwagi na lata przestępne.

tak, jest to znane jako Year 2038 problem, nadal po dziś dzień spotykam się z rozwiązaniami które przechowują daty w bazie na 32 bitach w unix timestamp, do 2038 prawdopodobnie większość zostanie poprawiona, ale nie wiem jak wy - ja sobie wtedy biorę urlop i postaram się nie być w tym momencie na przykład w samolocie :)

Tu lista znanych problemów z datami i jakie były/będą konsekwencje:
https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs

Widzę że nie rozumiecie sytuacji, zatem pomogę:
problem polega na tym, że programy tworzone z 20, czy nawet jeszcze 10 lat temu

A. były produkowane na 32-bitowe systemy
B. i dodatkowo - co jest kluczowe - producent nigdy nie przypuszczał, że klient będzie to używał przez 20 lat i dłużej.

czy ktoś sobie dzisiaj wyobraża że jego program, np. biurowy, będzie nadal używany w 2050r?
Wątpię, a tak będzie niestety jeśli program jest dobry, unikalny, dopasowany do potrzeb, itd.

OK.
Ale przeróbka tego czasu w postaci sekund, np. na minuty, przedłuży 60 razy czas użytkowania.

Pomysł uint32 zamiast int też jest niezły, bo tu w ogóle nie trzeba konwertować danych.