Обсуждение: Add FET to Default and Europe.txt
The attached patch would add the FET timezone abbreviation to the Default list _and_ the list of european abbreviations. - mb
Вложения
The Postgres community does not maintain the timezone database; we ship copies of the IANA timezone database; you will have to request the changes from them: http://www.iana.org/time-zones --------------------------------------------------------------------------- On Sat, Oct 6, 2012 at 11:18:43AM +0200, Marc Balmer wrote: > The attached patch would add the FET timezone abbreviation to the > Default list _and_ the list of european abbreviations. > > - mb > diff --git a/src/timezone/tznames/Default b/src/timezone/tznames/Default > index 1369f47..7223ce5 100644 > --- a/src/timezone/tznames/Default > +++ b/src/timezone/tznames/Default > @@ -615,6 +615,8 @@ EETDST 10800 D # East-Egypt Summertime > # (Europe/Uzhgorod) > # (Europe/Vilnius) > # (Europe/Zaporozhye) > +FET 10800 # Further-eastern European Time > + # (Europe/Minsk) > MEST 7200 D # Middle Europe Summer Time (not in zic) > MET 3600 # Middle Europe Time (not in zic) > METDST 7200 D # Middle Europe Summer Time (not in zic) > diff --git a/src/timezone/tznames/Europe.txt b/src/timezone/tznames/Europe.txt > index 88abecca..6c35ab1 100644 > --- a/src/timezone/tznames/Europe.txt > +++ b/src/timezone/tznames/Europe.txt > @@ -154,6 +154,8 @@ EETDST 10800 D # East-Egypt Summertime > # (Europe/Uzhgorod) > # (Europe/Vilnius) > # (Europe/Zaporozhye) > +FET 10800 # Further-eastern European Time > + # (Europe/Minsk) > GMT 0 # Greenwich Mean Time > # (Africa/Abidjan) > # (Africa/Bamako) > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce, > The Postgres community does not maintain the timezone database; we ship > copies of the IANA timezone database; you will have to request the > changes from them: > > http://www.iana.org/time-zones Please take a second look at the diffs, they do *NOT* change the files in the timezone database, they change the Default set ot timezones that PostgreSQL uses. These files are maintained by PostgreSQL, there is even a README with an explicit mention that changes should be reported to pgsql-hackers.... > > --------------------------------------------------------------------------- > > On Sat, Oct 6, 2012 at 11:18:43AM +0200, Marc Balmer wrote: >> The attached patch would add the FET timezone abbreviation to the >> Default list _and_ the list of european abbreviations. >> >> - mb > >> diff --git a/src/timezone/tznames/Default b/src/timezone/tznames/Default >> index 1369f47..7223ce5 100644 >> --- a/src/timezone/tznames/Default >> +++ b/src/timezone/tznames/Default >> @@ -615,6 +615,8 @@ EETDST 10800 D # East-Egypt Summertime >> # (Europe/Uzhgorod) >> # (Europe/Vilnius) >> # (Europe/Zaporozhye) >> +FET 10800 # Further-eastern European Time >> + # (Europe/Minsk) >> MEST 7200 D # Middle Europe Summer Time (not in zic) >> MET 3600 # Middle Europe Time (not in zic) >> METDST 7200 D # Middle Europe Summer Time (not in zic) >> diff --git a/src/timezone/tznames/Europe.txt b/src/timezone/tznames/Europe.txt >> index 88abecca..6c35ab1 100644 >> --- a/src/timezone/tznames/Europe.txt >> +++ b/src/timezone/tznames/Europe.txt >> @@ -154,6 +154,8 @@ EETDST 10800 D # East-Egypt Summertime >> # (Europe/Uzhgorod) >> # (Europe/Vilnius) >> # (Europe/Zaporozhye) >> +FET 10800 # Further-eastern European Time >> + # (Europe/Minsk) >> GMT 0 # Greenwich Mean Time >> # (Africa/Abidjan) >> # (Africa/Bamako) > >> >> -- >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-hackers > >
On Sat, Oct 6, 2012 at 02:46:03PM +0200, Marc Balmer wrote: > Bruce, > > > The Postgres community does not maintain the timezone database; we ship > > copies of the IANA timezone database; you will have to request the > > changes from them: > > > > http://www.iana.org/time-zones > > Please take a second look at the diffs, they do *NOT* change the files > in the timezone database, they change the Default set ot timezones that > PostgreSQL uses. > > These files are maintained by PostgreSQL, there is even a README with an > explicit mention that changes should be reported to pgsql-hackers.... > Oops, I see what you mean now. I thought everything under src/timezone was copied from others, but obviously I was wrong. --------------------------------------------------------------------------- > > > > > > --------------------------------------------------------------------------- > > > > On Sat, Oct 6, 2012 at 11:18:43AM +0200, Marc Balmer wrote: > >> The attached patch would add the FET timezone abbreviation to the > >> Default list _and_ the list of european abbreviations. > >> > >> - mb > > > >> diff --git a/src/timezone/tznames/Default b/src/timezone/tznames/Default > >> index 1369f47..7223ce5 100644 > >> --- a/src/timezone/tznames/Default > >> +++ b/src/timezone/tznames/Default > >> @@ -615,6 +615,8 @@ EETDST 10800 D # East-Egypt Summertime > >> # (Europe/Uzhgorod) > >> # (Europe/Vilnius) > >> # (Europe/Zaporozhye) > >> +FET 10800 # Further-eastern European Time > >> + # (Europe/Minsk) > >> MEST 7200 D # Middle Europe Summer Time (not in zic) > >> MET 3600 # Middle Europe Time (not in zic) > >> METDST 7200 D # Middle Europe Summer Time (not in zic) > >> diff --git a/src/timezone/tznames/Europe.txt b/src/timezone/tznames/Europe.txt > >> index 88abecca..6c35ab1 100644 > >> --- a/src/timezone/tznames/Europe.txt > >> +++ b/src/timezone/tznames/Europe.txt > >> @@ -154,6 +154,8 @@ EETDST 10800 D # East-Egypt Summertime > >> # (Europe/Uzhgorod) > >> # (Europe/Vilnius) > >> # (Europe/Zaporozhye) > >> +FET 10800 # Further-eastern European Time > >> + # (Europe/Minsk) > >> GMT 0 # Greenwich Mean Time > >> # (Africa/Abidjan) > >> # (Africa/Bamako) > > > >> > >> -- > >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > >> To make changes to your subscription: > >> http://www.postgresql.org/mailpref/pgsql-hackers > > > > > -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Marc Balmer <marc@msys.ch> writes:
> These files are maintained by PostgreSQL, there is even a README with an
> explicit mention that changes should be reported to pgsql-hackers....
What the README file actually suggests is that periodically we should
re-evaluate the set of default abbreviations. I'm not that thrilled
with making one-off changes on a first-to-complain basis.
I have no particular objection to adding FET, since it doesn't seem to
have any conflicts with other zone abbreviations; but we're really way
overdue for another global look at the abbreviation lists.
regards, tom lane
I wrote:
> What the README file actually suggests is that periodically we should
> re-evaluate the set of default abbreviations.
I looked through the diffs between the 2005m Olson time zone files
(which is what we were using at the time the tznames files were created)
and current. There are several issues that we need to deal with,
I think.
The biggest issue is that all of Russia has apparently (1) abandoned
daylight-savings time changes, and (2) settled on new "standard time"
zones that match up with their old DST times! For example we've got
*************** Zone Europe/Moscow 2:30:20 - LMT 1880
*** 1951,1967 **** 2:00 - EET 1930 Jun 21 3:00 Russia MSK/MSD 1991 Mar 31
2:00s 2:00 Russia EE%sT 1992 Jan 19 2:00s
! 3:00 Russia MSK/MSD # # From Oscar van Vlijmen (2001-08-25): [This region consists of] #
Samarskayaoblast', Udmyrtskaya respublika Zone Europe/Samara 3:20:36 - LMT 1919 Jul 1 2:00
! 3:00 - KUYT 1930 Jun 21 # Kuybyshev
! 4:00 Russia KUY%sT 1989 Mar 26 2:00s 3:00 Russia KUY%sT 1991 Mar 31 2:00s
2:00 Russia KUY%sT 1991 Sep 29 2:00s 3:00 - KUYT 1991 Oct 20 3:00
! 4:00 Russia SAM%sT # Samara Time # # From Oscar van Vlijmen (2001-08-25): [This region consists
of]# Respublika Bashkortostan, Komi-Permyatskij avtonomnyj okrug,
--- 2120,2155 ---- 2:00 - EET 1930 Jun 21 3:00 Russia MSK/MSD 1991 Mar 31
2:00s 2:00 Russia EE%sT 1992 Jan 19 2:00s
! 3:00 Russia MSK/MSD 2011 Mar 27 2:00s
! 4:00 - MSK
! #
! # Astrakhanskaya oblast', Kirovskaya oblast', Saratovskaya oblast',
! # Volgogradskaya oblast'. Shanks & Pottenger say Kirov is still at +0400
! # but Wikipedia (2006-05-09) says +0300. Perhaps it switched after the
! # others? But we have no data.
! Zone Europe/Volgograd 2:57:40 - LMT 1920 Jan 3
! 3:00 - TSAT 1925 Apr 6 # Tsaritsyn Time
! 3:00 - STAT 1930 Jun 21 # Stalingrad Time
! 4:00 - STAT 1961 Nov 11
! 4:00 Russia VOL%sT 1989 Mar 26 2:00s # Volgograd T
! 3:00 Russia VOL%sT 1991 Mar 31 2:00s
! 4:00 - VOLT 1992 Mar 29 2:00s
! 3:00 Russia VOL%sT 2011 Mar 27 2:00s
! 4:00 - VOLT # # From Oscar van Vlijmen (2001-08-25): [This region consists of] # Samarskaya
oblast',Udmyrtskaya respublika Zone Europe/Samara 3:20:36 - LMT 1919 Jul 1 2:00
! 3:00 - SAMT 1930 Jun 21
! 4:00 - SAMT 1935 Jan 27
! 4:00 Russia KUY%sT 1989 Mar 26 2:00s # Kuybyshev 3:00 Russia KUY%sT 1991
Mar31 2:00s 2:00 Russia KUY%sT 1991 Sep 29 2:00s 3:00 - KUYT 1991 Oct 20
3:00
! 4:00 Russia SAM%sT 2010 Mar 28 2:00s # Samara Time
! 3:00 Russia SAM%sT 2011 Mar 27 2:00s
! 4:00 - SAMT
! # # From Oscar van Vlijmen (2001-08-25): [This region consists of] # Respublika Bashkortostan, Komi-Permyatskij
avtonomnyjokrug,
Thus for example "MSK" apparently now means GMT+4 not GMT+3. We can
change the tznames entry for that, but should we get rid of "MSD"
entirely? Some input from the Russians on this list would be helpful.
Lesser issues:
* The FET changes you noted, which seem to be related to the whole
Russian change.
* Mongolia seems to have moved an hour east too, but they kept summer
time:
*** 1268,1278 **** Zone Asia/Choibalsan 7:38:00 - LMT 1905 Aug 7:00 - ULAT 1978
8:00 - ULAT 1983 Apr
! 9:00 Mongol CHO%sT # Choibalsan Time # Nepal # Zone NAME GMTOFF RULES FORMAT
[UNTIL]
--- 1783,1794 ---- Zone Asia/Choibalsan 7:38:00 - LMT 1905 Aug 7:00 - ULAT 1978
8:00 - ULAT 1983 Apr
! 9:00 Mongol CHO%sT 2008 Mar 31 # Choibalsan Time
! 8:00 Mongol CHO%sT # Nepal # Zone NAME GMTOFF RULES FORMAT [UNTIL]
* MAWT (Antarctica/Mawson) now means GMT+5 not GMT+6, and
Antarctica/Macquarie has adopted its very own zone name MIST. It looks
from the Olson database as though all of the Australian Antarctic
stations have changed their clocks from time to time without changing
the zone abbreviations they use. I'm inclined to mark all of them with
a cautionary note that the abbreviation has meant different things in
the past.
* Bangladesh now observes summer time, with abbreviation BDST. The
issue that this poses is that it conflicts with the existing Default
entry for British Double Summer Time, an acronym that hasn't been in use
since 1947. I'm inclined to think we should retire that one and give
the Default slot to Bangladesh Summer Time.
* Samoa, which decided to move themselves across the date line last
year, are now using WST and WSDT for GMT+13 and GMT+14. This conflicts
with Australia's use of WST for GMT+8. Fortunately we don't seem to
have ever adopted the latter into the Default list.
* Tokelau also moved across the date line, and we didn't update their
TKT entry for that.
* Some parts of Argentina are now using WART/WARST (Western Argentina)
zone names. This doesn't appear to conflict with anything so we might
as well adopt it into Default.
Comments?
regards, tom lane
On 6 October 2012 22:40, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thus for example "MSK" apparently now means GMT+4 not GMT+3. We can > change the tznames entry for that, but should we get rid of "MSD" > entirely? Some input from the Russians on this list would be helpful. ... > Comments? It shouldn't be our job to make decisions like this on behalf of the world. The TZ database clearly changes over time, so doing this accurately would mean we'd need to hold start and stop dates for each code so it can be used appropriately with specific times. Which would mean holding data in much finer detail that the source data, which is a little bizarre. * We should deprecate all use of timezone abbreviations in our internal code, if any. * Ship only the current tz file, as shipped by IANA with as few prep steps as possible * Make the tz file configurable, so people can be more explicit about what *they* mean by certain codes, to avoid the need for choosing between countries. For example, someone may have hardcoded particular codes with the understanding they relate to one particular TZ - if we make changes, we will alter the application logic, so that must be able to be "put back" for backwards compatibility. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 08.10.2012 10:03, Simon Riggs wrote: > On 6 October 2012 22:40, Tom Lane<tgl@sss.pgh.pa.us> wrote: > >> Thus for example "MSK" apparently now means GMT+4 not GMT+3. We can >> change the tznames entry for that, but should we get rid of "MSD" >> entirely? Some input from the Russians on this list would be helpful. > ... >> Comments? > > It shouldn't be our job to make decisions like this on behalf of the world. I wish it wasn't, too. But I don't think there's any "upstream" for this information. The tz library has abbreviations for timezones, but they're not unique. > * Make the tz file configurable, so people can be more explicit about > what *they* mean by certain codes, to avoid the need for choosing > between countries. For example, someone may have hardcoded particular > codes with the understanding they relate to one particular TZ - if we > make changes, we will alter the application logic, so that must be > able to be "put back" for backwards compatibility. It is configurable. See http://www.postgresql.org/docs/devel/static/datetime-config-files.html. We're just discussing what the defaults should be. - Heikki
On 8 October 2012 09:05, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: >> * Make the tz file configurable, so people can be more explicit about >> what *they* mean by certain codes, to avoid the need for choosing >> between countries. For example, someone may have hardcoded particular >> codes with the understanding they relate to one particular TZ - if we >> make changes, we will alter the application logic, so that must be >> able to be "put back" for backwards compatibility. > > > It is configurable. See > http://www.postgresql.org/docs/devel/static/datetime-config-files.html. > We're just discussing what the defaults should be. The problem there is that the default is "Default", so you have no idea what you are accepting and so are unlikely to be brave enough to alter it. If "default" were named "Postgres9" then people would at least understand that hackers had decided a few things and they might want to override it. So I think we need 2 new settings: one called "Postgres92", one called "Postgres93". 93 has the new settings and is the default. "Default" would no longer map to anything, to make sure we have an explicit break of compatibility. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Am 08.10.12 11:07, schrieb Simon Riggs: > On 8 October 2012 09:05, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > >>> * Make the tz file configurable, so people can be more explicit about >>> what *they* mean by certain codes, to avoid the need for choosing >>> between countries. For example, someone may have hardcoded particular >>> codes with the understanding they relate to one particular TZ - if we >>> make changes, we will alter the application logic, so that must be >>> able to be "put back" for backwards compatibility. >> >> >> It is configurable. See >> http://www.postgresql.org/docs/devel/static/datetime-config-files.html. >> We're just discussing what the defaults should be. > > The problem there is that the default is "Default", so you have no > idea what you are accepting and so are unlikely to be brave enough to > alter it. > > If "default" were named "Postgres9" then people would at least > understand that hackers had decided a few things and they might want > to override it. > > So I think we need 2 new settings: one called "Postgres92", one called > "Postgres93". 93 has the new settings and is the default. > > "Default" would no longer map to anything, to make sure we have an > explicit break of compatibility. Removing the timezone abbreviations from the default settings is probably the wrong approach. People use them, I use them, and my original request to add FET came from the fact that someone wanted to use it. As long as we have a type "timestamp with timezone", there should also be a way use and specify timezones in a "usual" format - by default. I think the problem we face is more of a maintainer nature than of a technical nature. Someone has to maintain this information. But then all other projects, mostly BSDs, that I was involved with, managed to keep this information more or less up to date. A good starting point would be to take the timezone information directly from the the files IANA distributes, instead of manually copying and maintaining them in a separate file. If no one else does, I can try to maintain these files. Those who know about my work, know that I do a lot of time related software (support for time signal receivers in OpenBSD, e.g.). So my vote - if I have one - is to keep the TZ information, but maybe maintain it better, if needed. Oh, and as a side note, I did not check how often the TZ database gets updated in PostgreSQL, if someone actually maintains it, I did not want to imply you do a bad job ;)
On 8 October 2012 11:14, Marc Balmer <marc@msys.ch> wrote: >> So I think we need 2 new settings: one called "Postgres92", one called >> "Postgres93". 93 has the new settings and is the default. >> >> "Default" would no longer map to anything, to make sure we have an >> explicit break of compatibility. > > Removing the timezone abbreviations from the default settings is > probably the wrong approach. People use them, I use them, and my > original request to add FET came from the fact that someone wanted to > use it. Sorry for any confusion. I've not suggested removing timezone abbreviations, nor do I wish to do so. I did suggest that we do not rely upon TZ abbreviations in any code shipped by PostgreSQL project, but I suspect that is a non-problem anyway. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Mon, Oct 8, 2012 at 12:14:15PM +0200, Marc Balmer wrote: > A good starting point would be to take the timezone information directly > from the the files IANA distributes, instead of manually copying and > maintaining them in a separate file. If no one else does, I can try to > maintain these files. Those who know about my work, know that I do a > lot of time related software (support for time signal receivers in > OpenBSD, e.g.). Could we pull an abbreviation list from one of the BSDs? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> writes:
> Could we pull an abbreviation list from one of the BSDs?
And that would be authoritative why?
regards, tom lane
On Mon, Oct 8, 2012 at 11:10:08AM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Could we pull an abbreviation list from one of the BSDs? > > And that would be authoritative why? It would be somone else maintaining it. :-) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Am 08.10.12 16:53, schrieb Bruce Momjian: > On Mon, Oct 8, 2012 at 12:14:15PM +0200, Marc Balmer wrote: >> A good starting point would be to take the timezone information directly >> from the the files IANA distributes, instead of manually copying and >> maintaining them in a separate file. If no one else does, I can try to >> maintain these files. Those who know about my work, know that I do a >> lot of time related software (support for time signal receivers in >> OpenBSD, e.g.). > > Could we pull an abbreviation list from one of the BSDs? Imo, the data should be pulled from the official source. Else an unneeded dependency from BSD is likely created...
On Mon, Oct 8, 2012 at 05:15:18PM +0200, Marc Balmer wrote: > Am 08.10.12 16:53, schrieb Bruce Momjian: > > On Mon, Oct 8, 2012 at 12:14:15PM +0200, Marc Balmer wrote: > >> A good starting point would be to take the timezone information directly > >> from the the files IANA distributes, instead of manually copying and > >> maintaining them in a separate file. If no one else does, I can try to > >> maintain these files. Those who know about my work, know that I do a > >> lot of time related software (support for time signal receivers in > >> OpenBSD, e.g.). > > > > Could we pull an abbreviation list from one of the BSDs? > > Imo, the data should be pulled from the official source. Else an > unneeded dependency from BSD is likely created... I thought there was no official source of abbreviations that deals with duplicates by choosing the most appropriate one. Is there? Where is it? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Simon Riggs <simon@2ndQuadrant.com> writes:
> Sorry for any confusion. I've not suggested removing timezone
> abbreviations, nor do I wish to do so.
> I did suggest that we do not rely upon TZ abbreviations in any code
> shipped by PostgreSQL project, but I suspect that is a non-problem
> anyway.
No, we don't rely on them AFAIK; certainly we don't use them in data
output. But people expect to be able to use them in data input.
The idea of tracking date ranges in which a TZ abbreviation is valid
is an interesting one, but it's vastly more effort than I for one
am willing to put into the problem --- not just in coding the
infrastructure, but gathering and maintaining the source data.
[ reflects for a bit... ] I guess in principle we could pull change
information out of the IANA database rather than having to maintain it
ourselves. But still what you're suggesting is an awful lot of work.
The other thing that the abbreviation list files are doing for us is
providing a user-configurable way to resolve conflicting abbreviations,
for instance IST (the Indians and the Israelis both use this, but not to
mean the same thing). This requirement isn't ever going to go away.
The Default list represents some considered judgements as to what the
most widely useful set of abbreviations is. We don't get to abdicate
the position of having to make those judgements; nobody would thank us
for breaking their database configurations because we can't decide.
I still think that we need some input from actual Russians as to what
is the currently most useful set of abbreviations for Russian time
zones. Armchair speculation from the other side of the globe isn't
going to be helpful to them.
regards, tom lane
On 08.10.2012 18:26, Tom Lane wrote: > The other thing that the abbreviation list files are doing for us is > providing a user-configurable way to resolve conflicting abbreviations, > for instance IST (the Indians and the Israelis both use this, but not to > mean the same thing). This requirement isn't ever going to go away. Locale-specific abbreviation lists would be nice. While abbreviations are not unique globally, they have established meanings in particular countries and regions. For example, IST is not unique, but if you are in India (en_IN) and spell out IST, you probably mean Indian Standard time. - Heikki
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> On 08.10.2012 18:26, Tom Lane wrote:
>> The other thing that the abbreviation list files are doing for us is
>> providing a user-configurable way to resolve conflicting abbreviations,
>> for instance IST (the Indians and the Israelis both use this, but not to
>> mean the same thing). This requirement isn't ever going to go away.
> Locale-specific abbreviation lists would be nice.
Yeah, that's a good thought, although the lack of standardization of
locale names seems to make it a bit hard to implement. My first idea
was "look for a tznames file matching the value of LC_TIME, and if
found, concatenate its contents with 'Default'". But there are enough
ways to spell "en_IN" to make that a bit problematic, and besides which
a user in India might well be running with C locale anyway. Still,
there might be a useful incremental usability gain there.
We aren't ever going to get out of the need for user configurability
though. For instance, if a user in India writes "EST", is he thinking
of the Australian or American meaning? It's plausible that either might
be preferred, depending on who that user interacts with regularly.
regards, tom lane
On Mon, Oct 8, 2012 at 11:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Heikki Linnakangas <hlinnakangas@vmware.com> writes: >> On 08.10.2012 18:26, Tom Lane wrote: >>> The other thing that the abbreviation list files are doing for us is >>> providing a user-configurable way to resolve conflicting abbreviations, >>> for instance IST (the Indians and the Israelis both use this, but not to >>> mean the same thing). This requirement isn't ever going to go away. > >> Locale-specific abbreviation lists would be nice. > > Yeah, that's a good thought, although the lack of standardization of > locale names seems to make it a bit hard to implement. My first idea > was "look for a tznames file matching the value of LC_TIME, and if > found, concatenate its contents with 'Default'". But there are enough > ways to spell "en_IN" to make that a bit problematic, and besides which > a user in India might well be running with C locale anyway. Still, > there might be a useful incremental usability gain there. > > We aren't ever going to get out of the need for user configurability > though. For instance, if a user in India writes "EST", is he thinking > of the Australian or American meaning? It's plausible that either might > be preferred, depending on who that user interacts with regularly. That sounds pretty cool, but "coolness" isn't the right way to evaluate whether this is good or not. If we introduce cases where peoples' expectations are liable to be disappointed (e.g. - they get the wrong EST, and report a bug on that), then we "lose." We have, in effect, been treating the handling of time zones in a manner where we're imagining there's general agreement on their interpretation. We presently get "bug reports" (and are "losing"/"getting it not as right as would be nice") in cases where we leave TZ symbols out, where they could have been included. The scenario where we could unambiguously include time zones is where the symbols are unique. If we were to include *all* uniquely-named symbols, that would minimize the number of complaints about missing zones, whilst evading the cases where the symbols are non-unique. That might be worth considering, though it'll certainly attract complaints in that some odd-ball zones would be included whilst well-known ones wouldn't. I would tend to think that local variations (e.g. - having a list for LC_TIME=en_IN) heads us into a morass of complexity. As you suggest, two different people using en_IN might have different preferences for what EST should mean. That being said, if we had a way to configure preferred localizations, people could set up their own set of associations. You want your own morass? You can build it yourself... -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
Christopher Browne <cbbrowne@gmail.com> writes:
> The scenario where we could unambiguously include time zones is where
> the symbols are unique. If we were to include *all* uniquely-named
> symbols, that would minimize the number of complaints about missing
> zones, whilst evading the cases where the symbols are non-unique.
> That might be worth considering, though it'll certainly attract
> complaints in that some odd-ball zones would be included whilst
> well-known ones wouldn't.
That sounds good in the abstract ... however, consider that two of the
ambiguous abbreviations are EST and CST, which means that taking a hard
line would piss off every American east of the Mississippi, likewise
over half of Canada, not to mention some proportion of Australians.
Can you say "user revolt"? Projects have been forked for less.
We can't just refuse to deal with this ambiguity. We have to have some
very-low-pain way to install settings that will please those large
fractions of our user base. Moreover, if that very-low-pain way isn't
the exact same way it's been done for the last half dozen releases,
you'll already have managed to annoy those selfsame large fractions.
You'd better have a good reason for changing it.
regards, tom lane
On Mon, Oct 8, 2012 at 4:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > We can't just refuse to deal with this ambiguity. We have to have some > very-low-pain way to install settings that will please those large > fractions of our user base. Moreover, if that very-low-pain way isn't > the exact same way it's been done for the last half dozen releases, > you'll already have managed to annoy those selfsame large fractions. > You'd better have a good reason for changing it. As previously noted, there are two topics that are being discussed here: - how to allow users to configure their own timezone abbreviations and - how to keep the timezone abbreviations that we ship updated wrt zic changes Regarding configurability, we currently allow users (=administrators) to change their abbreviations to whatever they like to use. The "Default" file we provide has been taken from the set that used to be a list that we compiled in back in the 8.x days (and we had this egregious GUC "australian_timezones" that decided whether CST/EST was regarded to be US or Australian timezones - there was no such hack for any of the other ambiguities). These timezone abbreviations have developed over several decades, most of these decades without global communication in mind. They are full of inconsistencies and irregularities and IMHO any way to select a proper set for someone automatically is doomed to solve the problem only partially. Another funny ambiguity is that the EST timezone in Austalia could mean both Eastern Standard Time and Eastern Summer Time, having different offsets depending on what month of the year you're in... The fact that we don't hear more complaints about the sets actually suggests that most people are happy with our "Default" set. In fact, Marc could just add his FET timezone to his own installations and use it from there. His request to add it to our Default set however is perfectly valid and should be discussed. One thing that could be improved about configurability is the fact that if you're not an administrator of the database, i.e. if you don't have write access to where the timezones are defined, you're pretty much out of luck being able to define your own abbreviations. This is true in a shared hosting environment for example. Wrt updating the timezone abbreviation files, I guess what we need is a parser for the zic database, our own timezone files and a script that compares the two datasets and spits out any conflicts so that we can clean them up after manual inspection of the differences. I will see if I can come up with some scripts in this direction.
On Mon, Oct 8, 2012 at 4:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > for instance IST (the Indians and the Israelis both use this, but not to > mean the same thing). And Ireland btw. So I'm not sure if this goes anywhere but .... could we get away with picking the timezone with the matching abbreviation closest to the system timezone? -- greg