Re: Add FET to Default and Europe.txt - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Add FET to Default and Europe.txt
Date
Msg-id 9636.1349559634@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add FET to Default and Europe.txt  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add FET to Default and Europe.txt  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Selena Deckelmann
Date:
Subject: Re: setting per-database/role parameters checks them against wrong context
Next
From: Tom Lane
Date:
Subject: Re: Regarding identifying a foreign scan