Обсуждение: New timezones used in regression tests
84df54b22e8035addc7108abd9ff6995e8c49264 introduced timestamp constructors. In the regression tests, various time zones are tested, including America/Metlakatla. Now, if you configure using --with-system-tzdata, you'll get an error if that zone isn't there. Unfortunately, this is what I'm getting now when trying to build beta1 on Ubuntu 10.04 (lucid) with tzdata 2010i-1: SELECT make_timestamptz(1866, 12, 10, 0, 0, 0, 'America/Metlakatla') AT TIME ZONE 'UTC'; ! ERROR: time zone "America/Metlakatla" not recognized I can work around it by patching the regression tests, but it would be nice if some other zone would be used that wasn't "invented" in 2011. Christoph -- cb@df7cb.de | http://www.df7cb.de/
Re: To PostgreSQL Hackers 2014-05-12 <20140512214025.GA31202@msgid.df7cb.de> > 84df54b22e8035addc7108abd9ff6995e8c49264 introduced timestamp > constructors. In the regression tests, various time zones are tested, > including America/Metlakatla. Now, if you configure using > --with-system-tzdata, you'll get an error if that zone isn't there. > Unfortunately, this is what I'm getting now when trying to build beta1 > on Ubuntu 10.04 (lucid) with tzdata 2010i-1: > > SELECT make_timestamptz(1866, 12, 10, 0, 0, 0, 'America/Metlakatla') AT TIME ZONE 'UTC'; > ! ERROR: time zone "America/Metlakatla" not recognized > > I can work around it by patching the regression tests, but it would be > nice if some other zone would be used that wasn't "invented" in 2011. Fwiw, there is an updated tzdata version in lucid-updates (2014a-0ubuntu0.10.04), which wasn't used in the pgapt build env until now, hence the error. Still, the problem will remain on older systems, and choosing a different time zone for this test seems easy to change. Christoph -- cb@df7cb.de | http://www.df7cb.de/
Christoph Berg <cb@df7cb.de> writes:
> 84df54b22e8035addc7108abd9ff6995e8c49264 introduced timestamp
> constructors. In the regression tests, various time zones are tested,
> including America/Metlakatla. Now, if you configure using
> --with-system-tzdata, you'll get an error if that zone isn't there.
> Unfortunately, this is what I'm getting now when trying to build beta1
> on Ubuntu 10.04 (lucid) with tzdata 2010i-1:
I agree, that seems an entirely gratuitous choice of zone. It does
seem like a good idea to test a zone that has a nonintegral offset
from GMT, but we can get that from almost anywhere as long as we're
testing a pre-1900 date. There's no need to use any zones that aren't
long-established and unlikely to change.
I'm quite unimpressed by the dependency on Mars/Mons_Olympus, too ... that
might not fail *today*, but considering it's a real location, assuming it
is not in the IANA database seems like a recipe for future failure.
Maybe something like Nehwon/Lankhmar? Or maybe we should not try to be
cute but just test Foo/Bar.
regards, tom lane
On 13/05/14 11:16, Tom Lane wrote: > Christoph Berg <cb@df7cb.de> writes: >> 84df54b22e8035addc7108abd9ff6995e8c49264 introduced timestamp >> constructors. In the regression tests, various time zones are tested, >> including America/Metlakatla. Now, if you configure using >> --with-system-tzdata, you'll get an error if that zone isn't there. >> Unfortunately, this is what I'm getting now when trying to build beta1 >> on Ubuntu 10.04 (lucid) with tzdata 2010i-1: > I agree, that seems an entirely gratuitous choice of zone. It does > seem like a good idea to test a zone that has a nonintegral offset > from GMT, but we can get that from almost anywhere as long as we're > testing a pre-1900 date. There's no need to use any zones that aren't > long-established and unlikely to change. > > I'm quite unimpressed by the dependency on Mars/Mons_Olympus, too ... that > might not fail *today*, but considering it's a real location, assuming it > is not in the IANA database seems like a recipe for future failure. > Maybe something like Nehwon/Lankhmar? Or maybe we should not try to be > cute but just test Foo/Bar. > > regards, tom lane > > You might like to consider the Chatham Islands, they are offset by 45 minutes: (GMT +12:45 / GMT +13:45)! Cheers, Gavin
On Mon, May 12, 2014 at 7:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I'm quite unimpressed by the dependency on Mars/Mons_Olympus, too ... that > might not fail *today*, but considering it's a real location, assuming it > is not in the IANA database seems like a recipe for future failure. > Maybe something like Nehwon/Lankhmar? Or maybe we should not try to be > cute but just test Foo/Bar. Personally, I think it would be *awesome* if our regression tests started failing due to the establishment of Mars/Mons_Olympus as a real time zone. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: Robert Haas 2014-05-13 <CA+TgmobVo--RCSrZ-U5fMa0Mo9XVpRptwevSW78oDceqJcMtkQ@mail.gmail.com> > On Mon, May 12, 2014 at 7:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I'm quite unimpressed by the dependency on Mars/Mons_Olympus, too ... that > > might not fail *today*, but considering it's a real location, assuming it > > is not in the IANA database seems like a recipe for future failure. > > Maybe something like Nehwon/Lankhmar? Or maybe we should not try to be > > cute but just test Foo/Bar. > > Personally, I think it would be *awesome* if our regression tests > started failing due to the establishment of Mars/Mons_Olympus as a > real time zone. Of course, Wikipedia has something to say about this: http://en.wikipedia.org/wiki/Timekeeping_on_Mars I especially like MTC, Mars Time Coordinated. But whatever scheme gets chosen, it won't be a standard 24h day, so PostgreSQL has a whole lot of different problems to solve than to "fix" that little Mars/Mons_Olympus gem now... :) Christoph -- cb@df7cb.de | http://www.df7cb.de/
Tom Lane wrote: > Christoph Berg <cb@df7cb.de> writes: > > 84df54b22e8035addc7108abd9ff6995e8c49264 introduced timestamp > > constructors. In the regression tests, various time zones are tested, > > including America/Metlakatla. Now, if you configure using > > --with-system-tzdata, you'll get an error if that zone isn't there. > > Unfortunately, this is what I'm getting now when trying to build beta1 > > on Ubuntu 10.04 (lucid) with tzdata 2010i-1: > > I agree, that seems an entirely gratuitous choice of zone. Well, it wasn't entirely gratuituous -- it had a very large offset from UTC to one direction and made a sudden jump to the opposite direction in 1900. Obviously I didn't notice the timezone had been created in 2011. (I bet if this hadn't been tried in a platform with such an old tzdata, this wouldn't have been noticed. Don't Ubuntu update tzdata on their LTS platforms!?) > I'm quite unimpressed by the dependency on Mars/Mons_Olympus, too ... that > might not fail *today*, but considering it's a real location, assuming it > is not in the IANA database seems like a recipe for future failure. > Maybe something like Nehwon/Lankhmar? Or maybe we should not try to be > cute but just test Foo/Bar. I liked Mars/Mons_Olympus, but Nehwon/Lankhmar is good too. /me adds more to his to-read list -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Christoph Berg wrote: > Of course, Wikipedia has something to say about this: > http://en.wikipedia.org/wiki/Timekeeping_on_Mars Nice. > I especially like MTC, Mars Time Coordinated. But whatever scheme gets > chosen, it won't be a standard 24h day, so PostgreSQL has a whole lot > of different problems to solve than to "fix" that little > Mars/Mons_Olympus gem now... :) Maybe a new type, mars_timestamptz()? Or perhaps the celestial body name should be part of the typmod for standard timestamptz ...? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Re: Alvaro Herrera 2014-05-13 <20140513135526.GR6018@eldon.alvh.no-ip.org> > > I especially like MTC, Mars Time Coordinated. But whatever scheme gets > > chosen, it won't be a standard 24h day, so PostgreSQL has a whole lot > > of different problems to solve than to "fix" that little > > Mars/Mons_Olympus gem now... :) > > Maybe a new type, mars_timestamptz()? Or perhaps the celestial body > name should be part of the typmod for standard timestamptz ...? Supporting other worlds would warrant bumping to PostgreSQL 10.0 :) Christoph -- cb@df7cb.de | http://www.df7cb.de/
On Mon, May 12, 2014 at 07:16:48PM -0400, Tom Lane wrote: > Christoph Berg <cb@df7cb.de> writes: > > 84df54b22e8035addc7108abd9ff6995e8c49264 introduced timestamp > > constructors. In the regression tests, various time zones are tested, > > including America/Metlakatla. Now, if you configure using > > --with-system-tzdata, you'll get an error if that zone isn't there. > > Unfortunately, this is what I'm getting now when trying to build beta1 > > on Ubuntu 10.04 (lucid) with tzdata 2010i-1: > > I agree, that seems an entirely gratuitous choice of zone. It does > seem like a good idea to test a zone that has a nonintegral offset > from GMT, but we can get that from almost anywhere as long as we're > testing a pre-1900 date. There's no need to use any zones that aren't > long-established and unlikely to change. If we want a nonintegral offset, why are we not using 'Asia/Calcutta', which is +5:30 from UTC? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Bruce Momjian <bruce@momjian.us> writes:
> On Mon, May 12, 2014 at 07:16:48PM -0400, Tom Lane wrote:
>> I agree, that seems an entirely gratuitous choice of zone. It does
>> seem like a good idea to test a zone that has a nonintegral offset
>> from GMT, but we can get that from almost anywhere as long as we're
>> testing a pre-1900 date. There's no need to use any zones that aren't
>> long-established and unlikely to change.
> If we want a nonintegral offset, why are we not using 'Asia/Calcutta',
> which is +5:30 from UTC?
I believe there's already one of those tests that considers a zone like
that. No, I meant a really odd offset, like Paris' +0:09:21 before they
adopted standardized time.
regards, tom lane
On Tue, May 13, 2014 at 09:55:26AM -0400, Alvaro Herrera wrote: > Christoph Berg wrote: > > > Of course, Wikipedia has something to say about this: > > http://en.wikipedia.org/wiki/Timekeeping_on_Mars > > Nice. > > > I especially like MTC, Mars Time Coordinated. But whatever scheme gets > > chosen, it won't be a standard 24h day, so PostgreSQL has a whole lot > > of different problems to solve than to "fix" that little > > Mars/Mons_Olympus gem now... :) > > Maybe a new type, mars_timestamptz()? Or perhaps the celestial body > name should be part of the typmod for standard timestamptz ...? The latter seems a good bit more extensible. Conversions among the different timestamptzs might be problematic, as we are currently assuming certain approximations about spacetime that don't actually hold when we have time zones in significantly different reference frames. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Thu, May 15, 2014 at 02:47:21PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > On Mon, May 12, 2014 at 07:16:48PM -0400, Tom Lane wrote: > >> I agree, that seems an entirely gratuitous choice of zone. It does > >> seem like a good idea to test a zone that has a nonintegral offset > >> from GMT, but we can get that from almost anywhere as long as we're > >> testing a pre-1900 date. There's no need to use any zones that aren't > >> long-established and unlikely to change. > > > If we want a nonintegral offset, why are we not using 'Asia/Calcutta', > > which is +5:30 from UTC? > > I believe there's already one of those tests that considers a zone like > that. No, I meant a really odd offset, like Paris' +0:09:21 before they > adopted standardized time. Wow, OK, got it. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +