I am seeing a problem with _ltzset near daylight savings time when non-POSIX TZ values are used. Here is the output of a program that locates discontinuities in the time (seconds since epoch are increased by 3600; check if hour increased by one): gap % tzcheck TZ=PST8PDT 720005582: 9/25/92 1:33 733919582: 3/4/93 3:33 752059982: 9/31/93 1:33 ^C gap % setenv TZ US/Pacific gap % tzcheck TZ=US/Pacific 720034366: 9/25/92 9:32 733948366: 3/4/93 11:32 752088766: 9/31/93 9:32 It's off by the GMT offset, 8 hours, in every case. If EST5EDT and US/Easter are used, it's off by 5 hours. Has anyone seen or fixed this problem? This is on SVR4. joel tornatore jrt@eng.sun.com
Joel,
gap % tzcheck TZ=PST8PDT 720005582: 9/25/92 1:33 733919582: 3/4/93 3:33 752059982: 9/31/93 1:33 ^C gap % setenv TZ US/Pacific gap % tzcheck TZ=US/Pacific 720034366: 9/25/92 9:32 733948366: 3/4/93 11:32 752088766: 9/31/93 9:32
It's off by the GMT offset, 8 hours, in every case. If EST5EDT and US/Easter are used, it's off by 5 hours.
Has anyone seen or fixed this problem? This is on SVR4.
How does your system differentiate between POSIX-style and ado-style TZ values? Vanilla ado code tries ado-style first, but more-compliant (== less-useful) implementations may only go with POSIX-style unless the string begins with ':'. Give ``TZ=:US/Pacific'' a burl. Brad
participants (2)
-
Bradley White -
Joel.Tornatore＠Eng.Sun.COM