glibc-2.7 i TimeZone

[Jakub Bogusz]

On Tue, Oct 30, 2007 at 09:59:35PM +0000, Szymon Siwek wrote:
> Witam!
> 
> $ date
> Tue Oct 30 21:40:28 UTC 2007
> $ TZ=GMT date
> Tue Oct 30 21:40:38 GMT 2007
> $ TZ=CET date
> Tue Oct 30 21:40:48 CET 2007
> $ TZ=CEST date
> Tue Oct 30 21:40:58 CEST 2007

"CEST" nie jest obsługiwanym oznaczeniem, więc jest traktowane jako UTC.
Odnośnie GMT vs CET nie zaobserwowałem takiego zachowania, nawet przed
poprawką w tzfile.c.

BTW, zgłosiłeś ją do upstreamu?

> Odnoszę wrażenie, że coś tu nie gra.
> 
> glibc-2.7-3.i686
> coreutils-6.9-2.i686
> 
> Druga sprawa - na tymże glibcu nie można zbudować tzdata.spec.
> Końcówka budownia:
> 
> timezone: -32400
> *** Timezone: Asia/Tokyo, daylight is: 0 but should be: 1
> *** Timezone: Asia/Tokyo, tzname[1] is: JST but should be: JDT

Tu jest problem z dokumentacją.
POSIX-owe manuale nie mówią wyraźnie, kiedy localtime() ma ustawiać
informacje o czasie letnim, a linuksowy manual jest niejednoznaczny
("daylight to a non-zero value if daylight savings time rules apply
during some part of the year" - którego roku? tego z daty,
późniejszego, wcześniejszego?).

W efekcie aktualny glibc ustawia tylko jeśli czas letni wystąpi od
chwili podanej przez parametr localtime().
W Japonii ostatnia zmiana czasu była w 1951 roku, więc ogólnie
działające tzset() podaje informacje o dwóch czasach, a localtime() dla
czasu po tym roku - tylko o jednym.

W glibc wycięli ten test z tst-timezone.c, więc może i tak ma być.
Ale z drugiej strony - w implementacji localtime() z tzcode daylight
(i druga nazwa czasu) ustawiane są zawsze jeśli kiedykolwiek czas letni
wystąpił; przy localtime(&t) zmieniana jest najwyżej nazwa czasu
obowiązującego w chwili t. A w glibc zachowanie daylight i drugiej nazwy
zmieniło się właśnie przy okazji naprawiania nazwy strefy czasowej
dla localtime() [BZ#1140]. Może więc należałoby to zgłosić jako błąd do
wyjaśnienia.


-- 
Jakub Bogusz    http://qboosh.pl/