| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Dmitry Funk <diffor(at)gmail(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #5466: Asia/Novosibirsk timezone problem |
| Date: | 2010-05-19 20:19:45 |
| Message-ID: | 24190.1274300385@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> Excerpts from Magnus Hagander's message of mi may 19 15:17:50 -0400 2010:
>> Well, if we report it as Novosibirsk, it will have DST. Which users in
>> Almaty aren't supposed to have, so it'll be wrong for them. So it's
>> going to be wrong for one of them whichever way we go, won't it?
> I meant that the Windows timezone does have DST, so users in Almaty are
> already screwed, but by Microsoft, not us.
According to the zic entry, Almaty has observed DST for most of the
zone's history. It might well choose to do so again someday. So we
should not imagine that "no DST" is an essential aspect of that zone.
AFAICS we don't really have any way to choose what to do here other
than making the default work for whichever zone is more populous.
Anyone know?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Enke | 2010-05-19 22:34:22 | Re: BUG #5464: ecpg on 64bit system converts "long long" to "long" |
| Previous Message | Alvaro Herrera | 2010-05-19 19:23:15 | Re: BUG #5466: Asia/Novosibirsk timezone problem |