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?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Patrick Welche
Дата:
Сообщение: Re: [HACKERS] COPY problems with psql / libpq
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Re: [HACKERS] off topic