[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 7.2C i pluskwa milenijna :(
At 01:12 00-01-07 +0100, you wrote:
> SCO UNIX System V/386 Release 3.2 Version 4.2
>
> DBServ,ClientNet,ServNet,4GLClient,ExtTools 7.2C
> data systemowa 01/01/2000
> w .pf -yy 1980
>
> stukam w procedure editor
> def var x as date.
> x=01/01/01.
> disp x format "9999-99-99".
>
> i otrzymuje 1901-01-01.
> ?????????????????
> co jeszcze ustawic zeby progress nie
> lekcewazyl yy (sprawdzilem w dictionary ze widzi poprawnie)
>
> Czy tak stara wersja moze zostac zfixowana
> jakims dostepnym patchem (gdzie?) ?
> Ten system mial umrzec dlugo przed 2k
> ale niestety przezyl
Wydaje mi się, że ten przykład jak i dalsza dyskusja nie dotyczą istoty
tematu.
1) Daty podawane w proceurach Progressa literalnie (jako stałe) są zawsze w
formacie "mdy", niezależnie od ustawienia parametru -d, co wystarczy
przeczytać w dokumentacji. To, że nie zależą od parametru -d jest rozsądnym
założeniem, bo jego zmiana powodowałaby ich inną interpretację, co z kolei
jest sprzeczne z literalnym umieszczeniem ich w programie, gdzie piszący
programista miał na myśli określoną datę, niezależnie od tego jaki parametr
-d ustawi użutkownik procedury
2) Powyższy przykład świadczy tylko o jednym, że podczas konwersji
literałów na wewnętrzną (binarną) postać daty Progress ignoruje parametr
-yy i przyjmuje domyślne ustawienie -yy 1900 co poniekąd jest też
zrozumiałe z przyczyn jak wyżej. Sprawdziłem w wersjach 7.2c. 7.3C, 8.1A -
we wszystkich jest tak samo jak w cytowanym przykładzie. nataomiast w
wersji 9.0B jest inaczej. W tej wersji, w czasie konwersji literału
parametr -yy jest uwzględniany. Czy to dobrze to wcale nie jestem taki
pewny, natomiast jestem przekonany, że ta poprawka powstała na fali 2000
albo jest efektem niezamierzonym.
3) Powyższa włąsność Progress'a (bo nie mówiłbym tutaj o błędzie) wcale nie
przeszkadza w jego poprawnym użytkowaniu przez całe najbliższe tysiąclecie,
bo wczytywanie dat z ekranu, wyswietlanie ich na ekran oraz operacje na
nich działają poprawnie. Jeśłi już coś trzeba poprawić, to tylko te miejsca
w programach, gdzie wartość daty jest zadawana jako literał. Myślę, że w
aplikacji jest bardzo mało takich miejsc, jeśli w ogóle są. Swoją drogą
programista, który powstawiał literały dat w formacie z dwucyfrowym rokiem
nie zachował się zbyt rozsądnie. Zresztą jeśli takie miejsca w aplikacji
są, to data w nich zadawana od zawsze była interpretowana tak samo i teraz
też będzie interpretowana tak samo. Jeśli to do tej pory nie przeszkadzało,
to i teraz to nie będzie przeszkadzało.
Wielu dziennikarzy oszalało na punkcie roku 2000 w komputerach (jak widać
sami stali się ofiarami rzeczywistości, którą wykreowali), ale my nie dajmy
się zwariować. Więcej racjonalnej analizy, mniej emocji.
Z życzeniami wszystkiego dobrego w nowym roku o dość "okrągłym" numerze w
jednym z obowiązujących świecie kalendarzy ...
Henryk Jusza henju@pg.gda.p
---------------------------------------------------------
Ośrodek Informatyczny Politechniki Gdańskiej
Pracownia Rozwoju Oprogramowania
tel (058) 347-28-01 fax (058) 347-24-63
------
Strona WWW: http://pluton.pol.lublin.pl/pugpl/index.htm
Obsluga listy: listserv@zeto.bydgoszcz.pl
Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html
------