October 2016 - tz - lists.iana.org

proposed time zone package changes (Samoa, Factory, et al.)
by Arthur David Olson Aug. 28, 2019

Aug. 28, 2019

Below find proposed time zone package changes; the executive summary: * Makefile Change LOCALTIME default from "Factory" to "GMT"; do not compile "factory" file (but keep it in the distribution). * Theory Remove reference to "Factory" zone. * australasia Change end of DST in Samoa in 2011 from 2011-04-03 0:00 to 2011-04-03 1:00 (thanks to Raymond Hughes for a reference). * localtime.c Initialize ttinfo structures filled by tzparse (thanks to Ravindra for reporting a valgrind warning). * zic.c Fix generation of POSIX strings for zones with rules using "weekday<=n" forms of dates (thanks to Lei Liu for finding the problem). Also, limit output for non-POSIX-specificable zones defined to follow the same rules every year. (Note that no zones of either of the above types appear in the distribution; these changes cater to add-on zones). If no problems are found, 2010n will appear on 2010-10-25. --ado diff -r -c old/Makefile new/Makefile *** old/Makefile Mon Sep 27 09:24:25 2010 --- new/Makefile Tue Oct 12 12:36:50 2010 *************** *** 1,5 **** # <pre> ! # @(#)Makefile 8.8 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)Makefile 8.9 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 12,18 **** # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= Factory # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, --- 12,18 ---- # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= GMT # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, *************** *** 262,269 **** DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera factory backward ! NDATA= systemv SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab --- 262,269 ---- DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera backward ! NDATA= systemv factory SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab diff -r -c old/Theory new/Theory *** old/Theory Mon Sep 27 09:24:25 2010 --- new/Theory Tue Oct 12 12:36:50 2010 *************** *** 1,4 **** ! @(#)Theory 8.4 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. --- 1,4 ---- ! @(#)Theory 8.5 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. *************** *** 287,294 **** See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', `EET' (see the file `europe'), ! and `Factory' (see the file `factory'). ----- Time zone abbreviations ----- --- 287,293 ---- See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', and `EET' (see the file `europe'). ----- Time zone abbreviations ----- diff -r -c old/australasia new/australasia *** old/australasia Mon Sep 27 09:24:27 2010 --- new/australasia Tue Oct 12 13:14:56 2010 *************** *** 1,5 **** # <pre> ! # @(#)australasia 8.18 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)australasia 8.19 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 487,497 **** # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </a> Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time -11:00 - WST 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 -11:00 - WST # Solomon Is --- 487,507 ---- # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </a> + # From Raymond Hughes (2010-10-07): + # Please see + # <a href="http://www.mcil.gov.ws"> + # http://www.mcil.gov.ws + # </a>, + # the Ministry of Commerce, Industry and Labour (sideframe) "Last Sunday + # September 2010 (26/09/10) - adjust clocks forward from 12:00 midnight + # to 01:00am and First Sunday April 2011 (03/04/11) - adjust clocks + # backwards from 1:00am to 12:00am" + Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time -11:00 - WST 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 1:00 -11:00 - WST # Solomon Is diff -r -c old/localtime.c new/localtime.c *** old/localtime.c Mon Sep 27 09:24:26 2010 --- new/localtime.c Tue Oct 12 12:36:51 2010 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.14"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.15"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 914,919 **** --- 914,920 ---- register unsigned char * typep; register char * cp; register int load_result; + static struct ttinfo zttinfo; INITIALIZE(dstname); stdname = name; *************** *** 986,991 **** --- 987,993 ---- /* ** Two transitions per year, from EPOCH_YEAR forward. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -dstoffset; sp->ttis[0].tt_isdst = 1; sp->ttis[0].tt_abbrind = stdlen + 1; *************** *** 1099,1106 **** } /* ** Finally, fill in ttis. - ** ttisstd and ttisgmt need not be handled. */ sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; --- 1101,1108 ---- } /* ** Finally, fill in ttis. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; *************** *** 1113,1118 **** --- 1115,1121 ---- dstlen = 0; sp->typecnt = 1; /* only standard time */ sp->timecnt = 0; + sp->ttis[0] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = 0; sp->ttis[0].tt_abbrind = 0; diff -r -c old/zic.c new/zic.c *** old/zic.c Mon Sep 27 09:24:26 2010 --- new/zic.c Tue Oct 12 13:37:29 2010 *************** *** 3,9 **** ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.22"; #include "private.h" #include "locale.h" --- 3,9 ---- ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.24"; #include "private.h" #include "locale.h" *************** *** 1881,1896 **** register int week; if (rp->r_dycode == DC_DOWGEQ) { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if ((week - 1) * DAYSPERWEEK + 1 != rp->r_dayofmonth) return -1; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if (week * DAYSPERWEEK - 1 != rp->r_dayofmonth) return -1; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", --- 1881,1896 ---- register int week; if (rp->r_dycode == DC_DOWGEQ) { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 1) return -1; + week = 1 + rp->r_dayofmonth / DAYSPERWEEK; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 0) return -1; + week = rp->r_dayofmonth / DAYSPERWEEK; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", *************** *** 2018,2023 **** --- 2018,2024 ---- register char * envvar; register int max_abbr_len; register int max_envvar_len; + register int prodstic; /* all rules are min to max */ max_abbr_len = 2 + max_format_len + max_abbrvar_len; max_envvar_len = 2 * max_abbr_len + 5 * 9; *************** *** 2032,2037 **** --- 2033,2039 ---- timecnt = 0; typecnt = 0; charcnt = 0; + prodstic = zonecount == 1; /* ** Thanks to Earl Chew ** for noting the need to unconditionally initialize startttisstd. *************** *** 2053,2058 **** --- 2055,2062 ---- updateminmax(rp->r_loyear); if (rp->r_hiwasnum) updateminmax(rp->r_hiyear); + if (rp->r_lowasnum || rp->r_hiwasnum) + prodstic = FALSE; } } /* *************** *** 2075,2080 **** --- 2079,2094 ---- if (max_year <= INT_MAX - YEARSPERREPEAT) max_year += YEARSPERREPEAT; else max_year = INT_MAX; + /* + ** Regardless of any of the above, + ** for a "proDSTic" zone which specifies that its rules + ** always have and always will be in effect, + ** we only need one cycle to define the zone. + */ + if (prodstic) { + min_year = 1900; + max_year = min_year + YEARSPERREPEAT; + } } /* ** For the benefit of older systems,

5 6

Syntax highlighting for Sublime Text
by Gilmore Davidson Aug. 16, 2017

Aug. 16, 2017

Hi, I’ve created some tzdata syntax highlighting rules for the Sublime Text editor: https://packagecontrol.io/packages/zoneinfo <https://packagecontrol.io/packages/zoneinfo> I have no idea if anyone other than me uses that particular text editor for looking at tzdata files. But I thought I’d mention it just in case it’s useful to someone. Cheers, Gil

3 3

Re: [tz] Version in zoneinfo files?
by Guy Harris Feb. 10, 2017

Feb. 10, 2017

On Oct 25, 2015, at 10:55 AM, Paul G <paul(a)ganssle.io> wrote: > I'm not suggesting that it be impossible to create a weird result when asking for the version, just that there's a standard place for the version to go, and preferably the standard default gives you something that you expected. I.e., something that works most of the time is sufficient? So what exactly is the intended use of this version field? > As it is now, you're virtually guaranteed to have a lot of incompatibility because there's nothing you can point to that says, "This is the canonical way to store version information about zoneinfo files", and no standard has emerged on how to do this as is. > > On 10/25/2015 01:51 PM, Guy Harris wrote: >> >> On Oct 25, 2015, at 10:37 AM, Paul G <paul(a)ganssle.io> wrote: >> >>> On 10/25/2015 01:35 PM, Guy Harris wrote: >>> >>>> So where would zic get the version information to put into the binary files? >>> >>> My understanding is that it's the VERSION= line of the Makefile in the tzdata tarballs. >> >> I.e., you're proposing that the value of the VERSION value in the Makefile be passed as an argument to zic, and zic would put the value of that argument into a field in the files? >> >> So, if the goal is to provide a "reliable way to get the version information in a cross-platform way", what would ensure that this field be set properly, for some value of "properly", everywhere that binary tzdata files are generated? >> >> I.e., what is to guarantee that >> >> 1) nobody downstream change VERSION if they aren't changing the zic files from what's distributed >> >> and >> >> 2) people change it "properly" if the files don't correspond to a particular version of files that were distributed (e.g., if some downstream supplier takes 2015q and adds some changes mentioned on the list to it before 2015r comes out with those changes plus other changes, they should call the resulting files something other than "2015q" or "2015r")? >> >

20 55

Proposal: validation text file with releases
by Jon Skeet Dec. 19, 2016

Dec. 19, 2016

Background: I'm the primary developer for Noda Time <http://nodatime.org> which consumes the tz data. I'm currently refactoring the code to do this... and I've come across some code (originally ported from Joda Time) which I now understand in terms of what it's doing, but not exactly why. For a little while now, the Noda Time source repo has included a text dump file <https://github.com/nodatime/nodatime/blob/master/src/NodaTime.Test/TestData…>, containing a text dump of every transition (up to 2100, at the moment) for every time zone. It looks like this, picking just one example: Zone: Africa/Maseru LMT: [StartOfTime, 1892-02-07T22:08:00Z) +01:52 (+00) SAST: [1892-02-07T22:08:00Z, 1903-02-28T22:30:00Z) +01:30 (+00) SAST: [1903-02-28T22:30:00Z, 1942-09-20T00:00:00Z) +02 (+00) SAST: [1942-09-20T00:00:00Z, 1943-03-20T23:00:00Z) +03 (+01) SAST: [1943-03-20T23:00:00Z, 1943-09-19T00:00:00Z) +02 (+00) SAST: [1943-09-19T00:00:00Z, 1944-03-18T23:00:00Z) +03 (+01) SAST: [1944-03-18T23:00:00Z, EndOfTime) +02 (+00) I use this file for confidence when refactoring my time zone handling code - if the new code comes up with the same set of transitions as the old code, it's probably okay. (This is just one line of defence, of course - there are unit tests, though not as many as I'd like.) It strikes me that having a similar file (I'm not wedded to the format, but it should have all the same information, one way or another) released alongside the main data files would be really handy for *all* implementors - it would be a good way of validating consistency across multiple platforms, with the release data being canonical. For any platforms which didn't want to actually consume the rules as rules, but just wanted a list of transitions, it could even effectively replace their use of the data. One other benefit: diffing the dump between two releases would make it clear what had changed in *effect*, rather than just in terms of rules. One sticking point is size. The current file for Noda Time is about 4MB, although it zips down to about 300K. Some thoughts around this: - We wouldn't need to distribute it in the same file as the data - just as we have data and code file, there could be a "textdump" file or whatever we'd want to call it. These could be retroactively generated for previous releases, too. - As you can see, there's redundancy in the format above, in that it's a list of "zone intervals" (as I call them in Noda Time) rather than a list of transitions - the end of each interval is always the start of the next interval. - For zones which settle into an infinite daylight saving pattern, I currently generate from the start of time to 2100 (and then a single zone interval for the end of time as Noda Time understands it; we'd need to work out what form that would take, if any). If we decided that "year of release + 30 years" was enough, that would cut down the size considerably. Any thoughts? If the feeling is broadly positive, the next step would be to nail down the text format, then find a willing victim/volunteer to write the C code. (You really don't want me writing C...) Jon

18 92

tzdata2016g missing version information
by Howard Hinnant Nov. 12, 2016

Nov. 12, 2016

As is known, the version number no longer appears in the Makefile. The release notes in NEWS say: > To support the more-accurate version number, its > specification has moved from a line in the Makefile to a new > source file 'version’. The version file does not appear in the uncompressed tzdata2016g database. This is hurting my ability to report the version of the database to my clients. Can we please put a version file in the database? Howard

18 49

Re: [tz] tzdata2016g missing version information
by Dempsey, Peter Nov. 10, 2016

Nov. 10, 2016

Hi, On 09/29/2016 08:590 AM, Eggert, Paul wrote: >Yes, it appears that the Oracle software assumed that the Makefile would have a VERSION line that specifies the version number. That assumption was never documented or guaranteed and is no longer valid. >Perhaps you can work around the problem by modifying the Makefile to say "VERSION = 2016g" (I don't have the Oracle software and so can't easily test this). >We are discussing a better way to address this problem in the future. @Paul Eggert: The Oracle Timezone Update Tool can be downloaded from here: http://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readm…. This tool has two ways of updating the timezone database: 1. Online where the timezone database is downloaded from: -l http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz 2. Offline where the timezone database is loaded locally: -l file:///tmp/tzdata2016g.tar.gz The tzdata file published on the IANA site needs to include the VERSION information so that this tool can work. When do you think this can be provided? I need to test the Oracle Timezone Updater Tool as soon as possible because I have customers with critical systems dependent on the time zone database. @Susan Abraham: I don't know if you are involved with the Timezone Updater Tool but this tool currently can't update the timezone because the database doesn't contain the VERSION information. @Kim Davies: I am adding you to keep you directly in the loop. Best regards, Pete -- This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail.

7 15

Compiler warning in tzcode2016g about SIZE_MAX being wider than int
by Tom Lane Nov. 6, 2016

Nov. 6, 2016

When trying to build 2016g using macOS's current compiler (or, probably, any reasonably late-model version of clang), I get cc -DTZDIR=\"/usr/local/etc/zoneinfo\" -c -o zic.o zic.c zic.c:434:51: warning: implicit conversion from 'unsigned long long' to 'int' changes value from 18446744073709551615 to -1 [-Wconstant-conversion] int amax = nitems_max < SIZE_MAX ? nitems_max : SIZE_MAX; ~~~~ ^~~~~~~~ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/stdint.h:153:20: note: expanded from macro 'SIZE_MAX' #define SIZE_MAX UINT64_MAX ^~~~~~~~~~ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/stdint.h:87:27: note: expanded from macro 'UINT64_MAX' #define UINT64_MAX 18446744073709551615ULL ^~~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. Or in other words, clang is pointing out, quite correctly, that SIZE_MAX won't fit in an int. This doesn't represent a runtime bug because the condition "nitems_max < SIZE_MAX" can never fail, but that just begs the question why have it. I am not aware of any C implementation that has ever had INT_MAX > SIZE_MAX, and surely there are none in use today. I suggest, therefore, a fix along the lines of $ diff -u zic.c~ zic.c --- zic.c~ 2016-09-06 00:39:50.000000000 -0400 +++ zic.c 2016-10-20 13:06:39.000000000 -0400 @@ -431,8 +431,7 @@ return ptr; else { int nitems_max = INT_MAX - WORK_AROUND_QTBUG_53071; - int amax = nitems_max < SIZE_MAX ? nitems_max : SIZE_MAX; - if ((amax - 1) / 3 * 2 < *nitems_alloc) + if ((nitems_max - 1) / 3 * 2 < *nitems_alloc) memory_exhausted(_("int overflow")); *nitems_alloc = *nitems_alloc + (*nitems_alloc >> 1) + 1; return erealloc(ptr, size_product(*nitems_alloc, itemsize)); Alternatively one might think of changing the types of nitems_max and amax to size_t --- but that would just make it even more crystal clear that the "nitems_max < SIZE_MAX" conditional is useless. And if, somewhere, one did find a C implementation in which size_t is narrower than int, that coding wouldn't work at all. Basically I don't see a way of dealing with this that is superior to just assuming that INT_MAX is less than or equal to SIZE_MAX. regards, tom lane

4 8

Tonga returns to DST on 2016-11-06
by Tim Parenti Nov. 6, 2016

Nov. 6, 2016

Tonga will observe DST from 2016-11-06 02:00 until 2017-01-15 03:00, in line with Fiji. http://mic.gov.to/news-today/press-releases/6375-daylight-saving-set-to-run… This came through as a pull request on the Github repo: https://github.com/eggert/tz/pull/19 Originally submitted patch and proposed follow-up attached. -- Tim Parenti

10 27

Why did you rename Russian zone name abbreviations
by Sergei Turchanov Nov. 3, 2016

Nov. 3, 2016

Hello! https://github.com/eggert/tz/commit/1ac038c2c3f25f7211474ae08feb6afb820 e35fe Why did you rename Russian zone name abbreviations? Can you provide a rationale for this change? This change breaks date parsing, etc... With best regards, Sergei Turchanov.

9 22

[PROPOSED PATCH] Cyprus is splitting into two time zones
by Paul Eggert Nov. 2, 2016

Nov. 2, 2016

Add a zone Asia/North_Nicosia for North Cyprus. * NEWS: Document this. * asia, zone.tab, zone1970.tab (Asia/North_Nicosia): New zone. --- NEWS | 5 +++-- asia | 11 ++++++++++- zone.tab | 3 ++- zone1970.tab | 3 ++- 4 files changed, 17 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index a4af3b2..64233bf 100644 --- a/NEWS +++ b/NEWS @@ -5,8 +5,9 @@ Unreleased, experimental changes Changes to future time stamps Turkey switched from EET/EEST (+02/+03) to permanent +03, - effective 2016-09-07. (Thanks to Burak AYDIN.) Use "+03" rather - than an invented abbreviation for the new time. + effective 2016-09-07. (Thanks to Burak AYDIN.) Northern Cyprus + followed suit the next day, which creates a zone Asia/North_Nicosia. + Use "+03" rather than an invented abbreviation for the new time. New leap second 2016-12-31 23:59:60 UTC as per IERS Bulletin C 52. (Thanks to Tim Parenti.) diff --git a/asia b/asia index e285326..4462cd4 100644 --- a/asia +++ b/asia @@ -773,6 +773,12 @@ Zone Asia/Macau 7:34:20 - LMT 1912 Jan 1 # Cyprus # # Milne says the Eastern Telegraph Company used 2:14:00. Stick with LMT. +# IATA SSIM (1998-09) has Cyprus using EU rules for the first time. +# +# From Paul Eggert (2016-09-09): +# Yesterday's Cyprus Mail reports that Northern Cyprus followed Turkey's +# lead and switched from +02/+03 to +03 year-round. +# http://cyprus-mail.com/2016/09/08/two-time-zones-cyprus-turkey-will-not-tur… # # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Cyprus 1975 only - Apr 13 0:00 1:00 S @@ -788,7 +794,10 @@ Rule Cyprus 1981 1998 - Mar lastSun 0:00 1:00 S Zone Asia/Nicosia 2:13:28 - LMT 1921 Nov 14 2:00 Cyprus EE%sT 1998 Sep 2:00 EUAsia EE%sT -# IATA SSIM (1998-09) has Cyprus using EU rules for the first time. +Zone Asia/North_Nicosia 2:13:27 - LMT 1921 Nov 14 + 2:00 Cyprus EE%sT 1998 Sep + 2:00 EUAsia EE%sT 2016 Sep 8 + 3:00 - +03 # Classically, Cyprus belongs to Asia; e.g. see Herodotus, Histories, I.72. # However, for various reasons many users expect to find it under Europe. diff --git a/zone.tab b/zone.tab index bf1bb71..15989f4 100644 --- a/zone.tab +++ b/zone.tab @@ -152,7 +152,8 @@ CU +2308-08222 America/Havana CV +1455-02331 Atlantic/Cape_Verde CW +1211-06900 America/Curacao CX -1025+10543 Indian/Christmas -CY +3510+03322 Asia/Nicosia +CY +3510+03322 Asia/Nicosia Cyprus (most areas) +CY +3511+03322 Asia/North_Nicosia North Cyprus CZ +5005+01426 Europe/Prague DE +5230+01322 Europe/Berlin Germany (most areas) DE +4742+00841 Europe/Busingen Busingen diff --git a/zone1970.tab b/zone1970.tab index 49f0b0b..efe27b1 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -144,7 +144,8 @@ CU +2308-08222 America/Havana CV +1455-02331 Atlantic/Cape_Verde CW,AW,BQ,SX +1211-06900 America/Curacao CX -1025+10543 Indian/Christmas -CY +3510+03322 Asia/Nicosia +CY +3510+03322 Asia/Nicosia Cyprus (most areas) +CY +3511+03322 Asia/North_Nicosia North Cyprus CZ,SK +5005+01426 Europe/Prague DE +5230+01322 Europe/Berlin Germany (most areas) DK +5540+01235 Europe/Copenhagen -- 2.7.4

11 23

Set up correct name to Zone Europe/Kyiv
by Alexey Furashev Oct. 31, 2016

Oct. 31, 2016

Hello All, In source file https://github.com/eggert/tz/blob/master/europe please change city name to correspondent standards ISO 3166-2:UA and UNGEGN. We have to write bug reports to software developers, because time zone entry names are incorrect. Incorrect name of time zone entries can't be used for our practical needs. ------------- str: 3663 from 'Zone Europe/Kiev' to 'Zone Europe/Kyiv' # ISO city code is UA-30 (https://www.iso.org/obp/ui/#iso:code:3166:UA ) ------------- str: 3691 from 'Zone Europe/Zaporozhye' to 'Zone Europe/Zaporizhzhia' ------------- Rules transliteraion from Ukranian to Latin see on site http://zakon4.rada.gov.ua/laws/show/55-2010-%D0%BF On-line service transliteration: https://dmsu.gov.ua/transliteration.html Oleksii. Kyiv.

2 1

Casey time zone change
by Steffen Thorsen Oct. 30, 2016

Oct. 30, 2016

Australian Antarctica Division informed us that Casey changed time zone to UTC+11 in "the morning of 22nd October 2016". The other Antarctic stations were not changed. Best regards, Steffen Thorsen - timeanddate.com

2 1

EU Parliament debates DST
by Matt Johnson Oct. 28, 2016

Oct. 28, 2016

Yesterday there was an extensive debate in the European Union Parliament concerning daylight saving time. The recordings and text are available here: http://www.europarl.europa.eu/plenary/en/debate-details.html?date=20161027&… Expand the section titled: "15:04 - 16:05 Switch between summer and winter time (debate)" My favorite is the passionate argument made by Indrek Tarand, MEP from Estonia, at 15:34:21. Though I'm not sure his history is quite so accurate. ;-) Thanks to http://www.timeanddate.com/news/time/eu-debate-dst.html for the heads up. -Matt

2 1

Historical discrepancies for Italy.
by Pierpaolo Bernardi Oct. 27, 2016

Oct. 27, 2016

Hello, about Italian time, I see: # From Paul Eggert (2006-03-22): # For Italian DST we have three sources: Shanks & Pottenger, Whitman, and # F. Pollastri # Day-light Saving Time in Italy (2006-02-03) # http://toi.iriti.cnr.it/uk/ienitlt.html # ('FP' below), taken from an Italian National Electrotechnical Institute # publication. When the three sources disagree, guess who's right, as follows: I don't know about the other sources, but: - the url given to cnr.it is dead. - The authoritative source for time in Italy is the national metrological institute, which has a summary page of historical DST data at http://www.inrim.it/res/tf/ora_legale_i.shtml - Some of the data in TZ does not agree with this page. I think that there must be VERY strong evidence that the INRIM is wrong before preferring other sources? Cheers

7 16

time update
by Tauʻolunga komipiuta Oct. 27, 2016

Oct. 27, 2016

Malo e lelei, people Are you already aware of the Tongan government's decision to introduce summertime? http://www.pmo.gov.to/daylight-saving-set-to-run-from-6-november-2016-to-15… Please update the tz database if you have not already done so. ʻOfa atu, Firitia >> Tauʻolunga komipiuta limited, Apple authorised reseller >> p.o.box 3060, Nukuʻalofa, Tonga >> Salote road, Fasi & afi; tel: 24828; fax: (+676)-24868, web: www.tau.olunga.to & facebook.tau.olunga.to

2 1

[PATCH] Introduce Epoch offset and local time Epoch
by Carsten Larsen Oct. 26, 2016

Oct. 26, 2016

--- localtime.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/localtime.c b/localtime.c index 6c00c45..3465248 100644 --- a/localtime.c +++ b/localtime.c @@ -58,6 +58,15 @@ static void unlock(void) { } #define OPEN_MODE O_RDONLY #endif /* !defined O_BINARY */ +/* +** AmigaOS Epoch is local time January 1, 1978 +*/ + +#ifdef AMIGAOS +#define TZEPOCH_OFFSET -252460800 +#define TZLOCAL_EPOCH 1 +#endif /* defined AMIGAOS */ + #ifndef WILDABBR /* ** Someone might make incorrect use of a time zone abbreviation: @@ -118,6 +127,12 @@ struct lsinfo { /* leap second information */ #ifndef TZNAME_MAX #define MY_TZNAME_MAX 255 #endif /* !defined TZNAME_MAX */ +#ifndef TZEPOCH_OFFSET +#define TZEPOCH_OFFSET 0 +#endif /* !defined TZEPOCH_OFFSET */ +#ifdef TZLOCAL_EPOCH +#define ALTZONE 1 +#endif /* defined TZLOCAL_EPOCH */ struct state { int leapcnt; @@ -2262,7 +2277,12 @@ posix2time(time_t t) time_t time(time_t *p) { - time_t r = sys_time(0); + time_t r = sys_time(0) + TZEPOCH_OFFSET; +#ifdef TZLOCAL_EPOCH + if(lcl_is_set) { + r += (!daylight ? timezone : altzone); + } +#endif if (p) *p = r; return r; -- 2.7.4

4 12

Balearics: Institutional declaration in favor of keeping the summer time
by Martin Kaistra Oct. 25, 2016

Oct. 25, 2016

Hello, According to https://www.theguardian.com/world/2016/oct/24/happy-hour-balearics-try-to-k… the Balearic Parliament will ask the central government to stay on summer time. Even though I don't think that this is happening this year, it might still be of interest to you. Parliament website (in Catalan?): http://www.parlamentib.es/webdocs/NoticiaPIB.aspx?id=2031 martin

1 0

Crimea time zone name
by Ilya Dogolazky Oct. 23, 2016

Oct. 23, 2016

Hello! According to Wikipedia the biggest city of Crimea is not Simferopol (2014 population: 332,317 [1]), because Sevastopol is a larger one (2016 population: 418,987 [2]). According to "Crimea" article, Sevastopol indeed is the biggest city of Crimea [3]. Is there any reason why the Crimea zone name is Europe/Simferopol and there is neither Europe/Sevastopol zone nor a symlink. Cheers, Ilya D. [1] https://en.wikipedia.org/wiki/Simferopol [2] https://en.wikipedia.org/wiki/Sevastopol [3] https://en.wikipedia.org/wiki/Crimea

2 1

Re: [tz] DST in the Netherlands before 1945
by Paul Eggert Oct. 21, 2016

Oct. 21, 2016

Thanks for spotting that typo. I installed the attached fix into the development repository.

1 0

Gwillim Law
by Paul Eggert Oct. 21, 2016

Oct. 21, 2016

I recently found out about Gwillim Law's passing by reading his family's web page <http://statoids.com/mgtletter.html>. Gwillim was a long time contributor to the tz project. He is credited in dozens of places, ranging from a 1993 decoding of entries for Tocantins in the International Air Transport Association's Standard Schedules Information Manual, to a 2015 translation of an article about a new time zone for Quintana Roo. Although I never met Gwillim in person, his expert, careful, and warm presence on the tz mailing list will be greatly missed. My condolences to his friends and family.

1 0

[tz-announce] 2016h release of tz code and data available
by Paul Eggert Oct. 20, 2016

Oct. 20, 2016

The 2016h release of the tz code and data is available. Its primary motivation is to update to the new rules for Palestine, where 2016g becomes incorrect starting about four hours from now (sorry, we didn't get much notice). More generally, the 2016h release reflects the following changes, which were either circulated on the tz mailing list or are relatively minor technical or administrative changes: Changes to future time stamps Asia/Gaza and Asia/Hebron end DST on 2016-10-29 at 01:00, not 2016-10-21 at 00:00. (Thanks to Sharef Mustafa.) Predict that future fall transitions will be on the last Saturday of October at 01:00, which is consistent with predicted spring transitions on the last Saturday of March. (Thanks to Tim Parenti.) Changes to past time stamps In Turkey, transitions in 1986-1990 were at 01:00 standard time not at 02:00, and the spring 1994 transition was on March 20, not March 27. (Thanks to Kıvanç Yazan.) Changes to past and future time zone abbreviations Asia/Colombo now uses numeric time zone abbreviations like "+0530" instead of alphabetic ones like "IST" and "LKT". Various English-language sources use "IST", "LKT" and "SLST", with no working consensus. (Usage of "SLST" mentioned by Sadika Sumanapala.) Changes to code zic no longer mishandles relativizing file names when creating symbolic links like /etc/localtime, when these symbolic links are outside the usual directory hierarchy. This fixes a bug introduced in 2016g. (Problem reported by Andreas Stieger.) Changes to build procedure New rules 'traditional_tarballs' and 'traditional_signatures' for building just the traditional-format distribution. (Requested by Deborah Goldsmith.) The file 'version' is now put into the tzdata tarball too. (Requested by Howard Hinnant.) Changes to documentation and commentary The 'Theory' file now has a section on interface stability. (Requested by Paul Koning.) It also mentions features like tm_zone and localtime_rz that have long been supported by the reference code. tz-link.htm has improved coverage of time zone boundaries suitable for geolocation. (Thanks to heads-ups from Evan Siroky and Matt Johnson.) The US commentary now mentions Allen and the "day of two noons". The Fiji commentary mentions the government's 2016-10-03 press release. (Thanks to Raymond Kumar.) Here are links to the release files: ftp://ftp.iana.org/tz/releases/tzcode2016h.tar.gz ftp://ftp.iana.org/tz/releases/tzdata2016h.tar.gz ftp://ftp.iana.org/tz/releases/tzdb-2016h.tar.lz The files are also available via HTTP as follows: http://www.iana.org/time-zones/repository/releases/tzcode2016h.tar.gz http://www.iana.org/time-zones/repository/releases/tzdata2016h.tar.gz http://www.iana.org/time-zones/repository/releases/tzdb-2016h.tar.lz As usual, links to the latest release files are here: http://www.iana.org/time-zones/repository/tzcode-latest.tar.gz http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz http://www.iana.org/time-zones/repository/tzdb-latest.tar.lz ftp://ftp.iana.org/tz/tzcode-latest.tar.gz ftp://ftp.iana.org/tz/tzdata-latest.tar.gz ftp://ftp.iana.org/tz/tzdb-latest.tar.lz Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit 6349f541e2183a00b9909af00b480c58955474cf dated 2016-10-19 23:17:57 -0700 and tagged '2016h' in the experimental github repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 109204356f8105b50d1e563c9a33f140a4af7ea38bfb720756f1fce863a346387d3897dfbd506da94fadcd10f35dc50d6475c6dfc047764dd308e21ee6291c18 tzcode2016h.tar.gz 8d4eeaebe39392ca9163d03601d1178597b3f0092419d1f54ebd34944110a0b10cb22d4ab8bacfb48bce3f6f7175177105e204f1b4edeadc38ad4ac2d6ded835 tzdata2016h.tar.gz fab2dd36b2c85a48d15cdbdbceb70ae6b30077cb83e582706b56d1e4dd24f945dede25ebd115b4bafa3e514a1d628c3d7f9a2da63f19f10942cd38dc8a16c155 tzdb-2016h.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJYCGLlAAoJEO2X6Q5iqn40hxQP/iamwTHAfVWNxb9yu+Xz8DeV 3kYZJF1ln6kkgmTqASn/L1m5VnaO8e4gVjwpYmkUavYUKZBCHkw9GxclNS5Qt3hI tDm2yE7vAvH23/zgo/NWeFtIzpp476W+VcIlCaSCo0iJ008rPxvIiBmFfgAg9Jji xUPYBBNHH1fLVIpyD2xCzwdeoDiJITX45CtWeGoT2uwA+4xbtfv1/NVMu8j7SN9w 7mpUTF2sAoMUdmG56TE0B8Y4vP3BwlqmVq8CadA4yj0DDwg+vyHKI7wkk9uP44+g DDmcZc9vK8P934veSsexNDLjdAxWSHkgcZ1IwGIPjl5/nquosPy5CdF6VqZFS+IX 9ruapyouZlXlfgg+I6pofkQw4WInO+tn0mIZxJHKXfv33aIxMU22m5ddvCJ0+hUf JIMgrkf0dGzlc8g2FT0DYVtDRg7Zik0GrszjmPc8jzeLi31oGxWA4Xjpwm8rYX/p 7kwIGwg3R19OwUaSgDjpEzXgXi3+iyNeLgq28YjhXj9p4iDhVUo+Njl8Kl31H1Vt 7gpo3utpRcT41nX/5yVUVcx4mJjvNwzD36/zc7hoTTQIInyrR5jQAZ5danDr/HCp NoK16D7WgbMaZMD0M0UV4RyTBlHKc0qeyL++xT7WLESCLxOpmVQdB/CYLjx0BZUr UAq95YoKcMMv+3KHjsDG =aC8a -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJYCGLlAAoJEO2X6Q5iqn40FNcP/RX7P5yEnZCRQ4FHHSFg9oIN Hsbp+7R9J9ap5egW8qPVu4HXzmbIzVbED/iCYWah+OMHI9ivJhRTVgPMhHcGco/k Qe8cb72EJIFc/N62BJyPoi48XqrDlw7bJGUuP0+bQGDG8Mik6RqTfOw3kUiUZT+y 9d/NfjQv8k/ASVxaag4FTKhcC9GeKHT51GDdFY9cRam4dgADXdqqsDAhPPeBeKrU hcZEtXaFYZzYvdBjmR7jK/2OYsSGatFeZY5aHxUi4dEmQ2WTv5/3nj6uOe1oHTjw X+xxrYcqINxPC3ss/VHT1fn8X1gQSsbAo/Vp9M9njdXCXCoOu/pSvpnyS4TZi/a6 CGSeGOr3Bz2hYQ1zIegr1QQgcgaK8LP/kl9IJ7dm6yBLVo0NZulzsJ9hRyZwDgWV +BhaPt5IZ0ktQNW8vU5HXrF7ic4qGdCKbcZOUr3DJaOcGHN92QpXS2cgvfZN/+8S uOWGdbCJIcaBmdfe3v9m4I/CKXi8ymb5ZXMDrPwkY6mDokqCG6s6Wfo++zlh1PPT E3Ix3HXfgYBrmByRxtJFwvI/l0VbzpfvOd4HcKuzWQltR5WYvPzdPB6HHLQGdsj7 2BFVXkFPKm1c0NMwB7u5xxvQiVRn1fjz+nLcP9BgZqASCVtREDu91GbRsNntFjzM MbBfIJc99AZIjc9hBjeI =dGny -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJYCGLlAAoJEO2X6Q5iqn40aGAP/iN1k3MtoTiYqnUR5NZyR6it c8grrRznviOPpjEk8/bfT0XpPGY1hwq1ctuuwHbylAFMVT7D4tM9csvDErP3bMNg ewDqBltrtLUzYEA66041AM3wLDTqe/lRqEXiNAPKSmulY4UM1FYHs9qpJ5rFXyOD bD6hkB0mppG/stQ3odfqM0EBZMPCjIZyPqZE4UcE4CY56ZN9R4Fa+R4urtyLRjhL OZqApSDeNtxX+cOPg5QlLO0jxhpO5649zjr7hCkHwXSi9Ji6CzKhiMz3RwJ9L4os VsX6Jg0QTZ68JVa3Zf+i/ysRCMvWQHvBxT3lG5aWrrrCpqvZKVgplFe/MSwbsMDH 3+5ws/+7aPS/QkeZo3WYS/0NisVgKUiKq5zH6PmhzfcfD0CMUUqS/fuHmP3cf1Vl rVRubxg0PgpThFLNdOMNa6c8L7lqzuV5Hwelq3yknM+1V02aTBHRFaU3Sh/gmest qRhb1GD+DO84Qm2JXL3kZXL1UGQq7EbH25r8DJAHHObx1TWyGTrLIE0MmS3LMZz5 zNzXMhaEBNufOQQz8LFwLJEiY4+WFem5VZAjE62GMl8iHhxCYJbuu+J3GeOcuP/l IFVLevVfoqa70CQTzKG7iEDhGwWmO3QdcmC261opbW1FPGnjiy+gOilayHse6ITX gt2dd+COJxgg7TlYv/vB =nbsq -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

Geolocation extension to tzdist
by Ken Murchison Oct. 20, 2016

Oct. 20, 2016

All, (sending to tz(a)iana.org since tzdist(a)ietf.org appears to be dead) I was bored today (actually avoiding "real" work) and was playing around with the ESRI shapefile for timezones <http://efele.net/maps/tz/world/> I hacked up a quick extension to my tzdist implementation using the tz_world shapefile and basic ray tracing to be able to query a time zone by geo coordinates, similar to what Google offers in their Time Zone API. Note that I have yet to spend any time writing code to account for "holes" in time zones like the Navajo Reservation in Arizona. I modeled the extension after the "find" action in RFC 7808 but with lat/long query params rather than a glob pattern. A request and response for the timezone in which my home is located looks something like this: GET /tzdist/zones?latitude=43.070833&longitude=-78.831667 HTTP/1.1 { "synctoken": "890939292-1466089793", "timezones": [ { "tzid": "America/New_York", "etag": "6602582-1466089793", "last-modified": "2016-06-16T15:09:53Z", "publisher": "IANA Time Zone Database", "version": "2016e", "aliases": [ "US/Eastern" ] } ] } The definition of the extension looks like this in the capabilities response: { "name": "geolocate", "uri-template": "/zones{?latitude,longitude}", "parameters": [ { "name": "latitude", "required": true }, { "name": "longitude", "required": true } ] } Currently my code only accepts coordinates in decimal degrees, but I think it should probably support ISO 6709 formats. Is this something that folks would like to see documented as a formal extension to tzdist, either as specified above or with some modification? If so, I'd be willing to write it up as a draft and then move it through IETF in whatever fashion the ADs recommend. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

4 5

[PATCH] Change abbreviation of Sri Lanka standard time to SLST
by Sadika Sumanapala Oct. 20, 2016

Oct. 20, 2016

According to http://www.sltime.org (maintained by Measurement Units, Standards & Services Department, Sri Lanka) abbreviation for Sri Lanka standard time is SLST. --- asia | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/asia b/asia index 71ef878..dcc8465 100644 --- a/asia +++ b/asia @@ -2768,6 +2768,10 @@ Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 # One possibility is that we wait for a bit for the dust to settle down # and then see what people actually say in practice. +# From Sadika Sumanapala (2016-10-18): +# According to http://www.sltime.org (Official web site of dissemation +# of standard time of Sri Lanka) abbreviation is SLST. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Colombo 5:19:24 - LMT 1880 5:19:32 - MMT 1906 # Moratuwa Mean Time @@ -2777,7 +2781,7 @@ Zone Asia/Colombo 5:19:24 - LMT 1880 5:30 - IST 1996 May 25 0:00 6:30 - LKT 1996 Oct 26 0:30 6:00 - LKT 2006 Apr 15 0:30 - 5:30 - IST + 5:30 - SLST # Syria # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -- 2.10.0

7 18

Palestine Summer Time wrong ending date
by Sharef Mustafa Oct. 19, 2016

Oct. 19, 2016

Hi, Regarding Palestine end of summer time (Asia/Gaza + Asia/Hebron), the current tz database shows that summer time will end on Oct 20th 2016, sharef@plug.ps:/usr/share/zoneinfo$ zdump -v Asia/Gaza | grep 2016 Asia/Gaza Fri Mar 25 22:59:59 2016 UT = Sat Mar 26 00:59:59 2016 EET isdst=0 gmtoff=7200 Asia/Gaza Fri Mar 25 23:00:00 2016 UT = Sat Mar 26 02:00:00 2016 EEST isdst=1 gmtoff=10800 Asia/Gaza Thu Oct 20 20:59:59 2016 UT = Thu Oct 20 23:59:59 2016 EEST isdst=1 gmtoff=10800 Asia/Gaza Thu Oct 20 21:00:00 2016 UT = Thu Oct 20 23:00:00 2016 EET isdst=0 gmtoff=7200 also for westbank Hebron sharef@plug.ps:/usr/share/zoneinfo$ zdump -v Asia/Hebron | grep 2016 Asia/Hebron Fri Mar 25 22:59:59 2016 UT = Sat Mar 26 00:59:59 2016 EET isdst=0 gmtoff=7200 Asia/Hebron Fri Mar 25 23:00:00 2016 UT = Sat Mar 26 02:00:00 2016 EEST isdst=1 gmtoff=10800 Asia/Hebron Thu Oct 20 20:59:59 2016 UT = Thu Oct 20 23:59:59 2016 EEST isdst=1 gmtoff=10800 Asia/Hebron Thu Oct 20 21:00:00 2016 UT = Thu Oct 20 23:00:00 2016 EET isdst=0 gmtoff=7200 However the Palestinian cabinet decision ( Mar 8th 2016) published on http://www.palestinecabinet.gov.ps/WebSite/Upload/Decree/GOV_17/16032016134… states that summer time will end on Oct 29th at 01:00 . There has been no recent updates from the government in this regard, I suggest to correct the end date accordingly. BR Sharef Mustafa

3 3

Suggestion for addition of America/Brasilia entry to time zone database
by Gabriel Gaspar Oct. 19, 2016

Oct. 19, 2016

Hello there, and sorry for the intrusion. I presently write to this list with a suggestion for addition of an entry in the time zone database, America/Brasilia, or at least for a clarification on why there may not be one. Being the standard official time in Brazil, I firmly believe there should be one such entry (unless, of course, matters of greater power disallow it). The official time used in Brazil is called "the Brasilia official time" (UTC -3:00), Brasilia being the capital of Brazil. Note that the official country name is Brasil, with an 's', and the official capital name is Brasília, with an acute on the first 'i'. I am writing the country name with 'z' and leaving the aforementioned acute out for internationalization purposes. Inside Brazilian territory, the remainder time zones are usually referred and adjusted having Brasilia time as a referential base, e.g. "Brasilia time +1", "Brasilia time -1" etc. Even more, event times in Brazil (games, DST start/end, official announcements) are all informed, be it via government official channels or mass media, in Brasilia's official time, further evidencing the importance of Brasilia as a reference for setting times inside country territory. That being said, I have always wondered why it is that Brasilia is not listed as one of the time zones in the data base for South America. It is the official time for Brazil and the name does not clash with any other name in the database (America/Brasilia). Instead, it is relegated to an indirect mention, (Brasilia is located inside Distrito Federal (DF)), in a comment for the time zone America/Sao_Paulo. São Paulo is a major city in Brazil, but by no means the capital itself, nor does it retain any authoritative power in setting or representing the official time, which Brasilia does. Actually, the America/Sao_Paulo time zone entry seems to be doing what an America/Brasilia time zone entry should be doing. Thus, my suggestion would be either for the addition of something such as America/Brasilia to the time zone database, or for the renaming of America/Sao_Paulo to America/Brasilia in order to more accurately represent what that time zone entry stands for. The former suggestion would add more information to the database, but other than occupying more space I fail to see further problems with that addition. The latter suggestion could break some scripts that rely on the time zone name for correct operation, although I currently have no knowledge of one such script nor how crucial its operation could be. Without further ado, I thank you for the time to read this, and appreciate the time for such considerations. Regards, Gabriel G. Gaspar

3 2