Re: [HACKERS] timezone problem?
| От | Thomas Lockhart |
|---|---|
| Тема | Re: [HACKERS] timezone problem? |
| Дата | |
| Msg-id | 38873D5F.1E7F83A5@alumni.caltech.edu обсуждение исходный текст |
| Ответ на | timezone problem? (Tatsuo Ishii <t-ishii@sra.co.jp>) |
| Ответы |
Re: [HACKERS] timezone problem?
|
| Список | pgsql-hackers |
> Well, we could solve a smaller problem: keep a list of the timezone
> names we think are equivalent to GMT. Then, if we see a zero TZ offset
> for any name not in the list, emit some sort of warning notice. Bit of
> a kluge though.
Uh, yes it is :)
> I am not sure that this relates to Tatsuo's complaint, though.
> His issue was:
> > test=> select '1998-09-23 12:05:10 HST'::datetime;
> > ------------------------------
> > Thu Sep 24 07:05:10 1998 JST
> > test=> show timezone;
> > NOTICE: Time zone is unknown
> If Postgres doesn't know the timezone, why is it displaying "JST" in
> decoded datetimes?
"Time zone is unknown" is the usual state if there is not an explicit
SET TIME ZONE by a client. Doesn't mean anything more, and doesn't
imply that the backend can't do timezone stuff. Postgres relies on
system-supplied routines if the year is between 1903 and 2038 (mas o
menos; I didn't look it up).
> Another odd thing is that I'd have expected the displayed time to be
> GMT if the system doesn't know the timezone --- but the time being
> shown here is 9 hours ahead of JST, not 9 hours behind... perhaps
> something somewhere *does* know the local zone, but is applying the
> correction backwards?
HST is interpreted by Postgres as Hawaii Standard Time, which is on
the other side of the date line from Japan. Planning a vacation
Tatsuo?? :))
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
В списке pgsql-hackers по дате отправления: