- tz - lists.iana.org

Bad 32 bit data in 2018f
by Daniel Fischer Oct. 25, 2018

Oct. 25, 2018

Hi, I'm getting bad data in the 32 bit section of some of the compiled files in zoneinfo-leaps. The affected time zones are zones that only transition before 1901, usually from LMT to some UTC offset: Indian/Christmas Indian/Cocos Atlantic/South_Georgia Pacific/Port_Moresby Pacific/Chuuk Pacific/Yap Pacific/Wallis Pacific/Funafuti Pacific/Palau Pacific/Ponape Pacific/Wake Pacific/Pohnpei Pacific/Truk Pacific/Tarawa The files in zoneinfo-leaps contain no transitions, and only the offset used before the transition. This causes applications that only read the 32 bit section to use LMT for these zones. The 64 bit section, and both sections in the zoneinfo version of these files, contain >=2 transitions and offsets (e.g. one real transition and one in 2038). For example, zdump with a break added after /old file/ in localtime.c: $ ./zdump $PWD/TZ/usr/share/zoneinfo*/Atlantic/South_Georgia .../TZ/usr/share/zoneinfo/Atlantic/South_Georgia Tue Oct 23 12:31:33 2018 -02 .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Tue Oct 23 12:04:58 2018 LMT $ ./zdump -V $PWD/TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Sat Jul 1 00:00:00 1972 UT = Fri Jun 30 21:33:52 1972 LMT isdst=0 gmtoff=-8768 .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Sat Jul 1 00:00:01 1972 UT = Fri Jun 30 21:33:52 1972 LMT isdst=0 gmtoff=-8768 [..] .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Sun Jan 1 00:00:27 2017 UT = Sat Dec 31 21:33:52 2016 LMT isdst=0 gmtoff=-8768 I found that before commit 83c119f4d ("Remove Big Bang hack"), the one offset present in the leaps version was the correct one. The structural difference is older; it just didn't affect my application because the offset was the one currently in use. The cause appears to be this sequence of events starting at zic.c /Work around QTBUG-53071/: 1) y2038_boundary-1 transition is added (== INT32_MAX) 2) leap seconds are added to all times, pushing the 2038 transition above INT32_MAX 3) affected zones again only have transition times outside the 32 bit range => timecnt32 is 0 4) because timecnt32 is 0, timei32 is also 0, and the INT32_MIN transition isn't output either 5) because of omittype[defaulttype] = false, the oldest offset is always output regardless of the above The workaround could probably be moved to after the leap seconds are added, especially if it's supposed to apply to the 32 bit leaps files. This will also fix this bug, because the code that determines the 32 bit limits assumes there's at least one time after 1901, and the workaround provides one. (This is why the non-leaps version is correct.) I'm unfortunately not familiar enough with the tz database to suggest a complete fix. Danny -- Daniel Fischer ORACLE Deutschland B.V. & Co. KG, Riesstr. 25, 80992 München - HRA MUC 95603 Komplementaer: ORACLE DE Verw.B.V., Hertogswetering 163/167, 3543 AS Utrecht Geschaeftsfuehrer: Alexander van der Ven, Jan Schultheiss, Val Maher NL

2 4

[PROPOSED] * northamerica: El Paso time zone rebellion.
by Paul Eggert Oct. 25, 2018

Oct. 25, 2018

--- northamerica | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/northamerica b/northamerica index fb0103f..9d5bad2 100644 --- a/northamerica +++ b/northamerica @@ -439,6 +439,19 @@ Zone America/North_Dakota/Beulah -6:47:07 - LMT 1883 Nov 18 12:12:53 # western South Dakota, far western Texas (El Paso County, Hudspeth County, # and Pine Springs and Nickel Creek in Culberson County), Utah, Wyoming # +# From Paul Eggert (2018-10-25): +# On 1921-03-04 federal law placed all of Texas into the central time zone. +# However, El Paso ignored the law for decades and continued to observe +# mountain time, on the grounds that that's what they had always done +# and they weren't about to let the federal government tell them what to do. +# Eventually the federal government gave in and changed the law on +# 1970-04-10 to match what El Paso was actually doing. Although +# that's slightly after our 1970 cutoff, there is no need to create a +# separate zone for El Paso since they were ignoring the law anyway. See: +# Long T. El Pasoans were time rebels, fought to stay in Mountain zone. +# El Paso Times. 2018-10-24 06:40 -06. +# https://www.elpasotimes.com/story/news/local/el-paso/2018/10/24/el-pasoans-… +# # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER Rule Denver 1920 1921 - Mar lastSun 2:00 1:00 D Rule Denver 1920 only - Oct lastSun 2:00 0 S -- 2.17.1

1 0

[PROPOSED] Add interoperability sections to tzfile.5
by Paul Eggert Oct. 25, 2018

Oct. 25, 2018

This change consists of text that I contributed to https://tools.ietf.org/html/draft-murchison-tzdist-tzif-15 and that should be useful generally. * NEWS, tzfile.5: New sections. --- NEWS | 4 ++ tzfile.5 | 192 ++++++++++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 195 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 943db3e..68f826e 100644 --- a/NEWS +++ b/NEWS @@ -16,6 +16,10 @@ Unreleased, experimental changes This reverts to 2011h, as the abbreviation change in 2011i was likely inadvertent. + Changes to documentation + + tzfile.5 has new sections on interoperability issues. + Release 2018f - 2018-10-18 00:14:18 -0700 diff --git a/tzfile.5 b/tzfile.5 index 79b19bf..bbdccfc 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -9,6 +9,8 @@ tzfile \- timezone information .de q \\$3\*(lq\\$1\*(rq\\$2 .. +.ie \n(.g .ds - \f(CW-\fP +.el ds - \- The timezone information files used by .BR tzset (3) are typically found under a directory with a name like @@ -186,8 +188,196 @@ from 0 through 24. Second, DST is in effect all year if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the difference between daylight saving and standard time. -.PP +.SS Interoperability considerations Future changes to the format may append more data. +.PP +Version 1 files are considered a legacy format and +should be avoided, as they do not support transition +times after the year 2038. +Readers that only understand Version 1 must ignore +any data that extends beyond the calculated end of the version +1 data block. +.PP +Writers should generate a version 3 file if +TZ string extensions are necessary to accurately +model transition times. +Otherwise, version 2 files should be generated. +.PP +The sequence of time changes defined by the version 1 +header and data block should be a contiguous subsequence +of the time changes defined by the version 2+ header and data +block, and by the footer. +This guideline helps obsolescent version 1 readers +agree with current readers about timestamps within the +contiguous subsequence. It also lets writers not +supporting obsolescent readers use a +.I tzh_timecnt +of zero +in the version 1 data block to save space. +.PP +Time zone designations should consist of at least three (3) +and no more than six (6) ASCII characters from the set of +alphanumerics, +.q "-", +and +.q "+". +This is for compatibility with POSIX requirements for +time zone abbreviations. +.PP +When reading a version 2 or 3 file, readers +should ignore the version 1 header and data block except for +the purpose of skipping over them. +.PP +Readers should calculate the total lengths of the +headers and data blocks and check that they all fit within +the actual file size, as part of a validity check for the file. +.SS Common interoperability issues +This section documents common problems in reading or writing TZif files. +Most of these are problems in generating TZif files for use by +older readers. +The goals of this section are: +.IP * 2 +to help TZif writers output files that avoid common +pitfalls in older or buggy TZif readers, +.IP * +to help TZif readers avoid common pitfalls when reading +files generated by future TZif writers, and +.IP * +to help any future specification authors see what sort of +problems arise when the TZif format is changed. +.PP +When new versions of the TZif format have been defined, a +design goal has been that a reader can successfully use a TZif +file even if the file is of a later TZif version than what the +reader was designed for. +When complete compatibility was not achieved, an attempt was +made to limit glitches to rarely-used timestamps, and to allow +simple partial workarounds in writers designed to generate +new-version data useful even for older-version readers. +This section attempts to document these compatibility issues and +workarounds, as well as to document other common bugs in +readers. +.PP +Interoperability problems with TZif include the following: +.IP * 2 +Some readers examine only version 1 data. +As a partial workaround, a writer can output as much version 1 +data as possible. +However, a reader should ignore version 1 data, and should use +version 2+ data even if the reader's native timestamps have only +32 bits. +.IP * +Some readers designed for version 2 might mishandle +timestamps after a version 3 file's last transition, because +they cannot parse extensions to POSIX in the TZ-like string. +As a partial workaround, a writer can output more transitions +than necessary, so that only far-future timestamps are +mishandled by version 2 readers. +.IP * +Some readers designed for version 2 do not support +permanent daylight saving time, e.g., a TZ string +.q "EST5EDT,0/0,J365/25" +denoting permanent Eastern Daylight Time (\*-04). +As a partial workaround, a writer can substitute standard time +for the next time zone east, e.g., +.q "AST4" +for permanent Atlantic Standard Time (\*-04). +.IP * +Some readers ignore the footer, and instead predict future +timestamps from the time type of the last transition. +As a partial workaround, a writer can output more transitions +than necessary. +.IP * +Some readers do not use time type 0 for timestamps before +the first transition, in that they infer a time type using a +heuristic that does not always select time type 0. +As a partial workaround, a writer can output a dummy (no-op) +first transition at an early time. +.IP * +Some readers mishandle timestamps before the first +transition that has a timestamp not less than -2**31. +Readers that support only 32-bit timestamps are likely to be +more prone to this problem, for example, when they process +64-bit transitions only some of which are representable in 32 +bits. +As a partial workaround, a writer can output a dummy +transition at timestamp \*-2**31. +.IP * +Some readers mishandle a transition if its timestamp has +the minimum possible signed 64-bit value. +Timestamps less than \*-2**59 are not recommended. +.IP * +Some readers mishandle POSIX-style TZ strings that +contain +.q "<" +or +.q ">". +As a partial workaround, a writer can avoid using +.q "<" +or +.q ">" +for time zone abbreviations containing only alphabetic +characters. +.IP * +Many readers mishandle time zone abbreviations that contain +non-ASCII characters. +These characters are not recommended. +.IP * +Some readers may mishandle time zone abbreviations that +contain fewer than 3 or more than 6 characters, or that +contain ASCII characters other than alphanumerics, +.q "-", +and +.q "+". +These abbreviations are not recommended. +.IP * +Some readers mishandle TZif files that specify +daylight-saving time UT offsets that are less than the UT +offsets for the corresponding standard time. +These readers do not support locations like Ireland, which +uses the equivalent of the POSIX TZ string +.q "IST\*-1GMT0,M10.5.0,M3.5.0/1", +observing standard time +(IST, +01) in summer and daylight saving time (GMT, +00) in winter. +As a partial workaround, a writer can output data for the +equivalent of the POSIX TZ string +.q "GMT0IST,M3.5.0/1,M10.5.0", +thus swapping standard and daylight saving time. +Although this workaround misidentifies which part of the year +uses daylight saving time, it records UT offsets and time zone +abbreviations correctly. +.PP +Some interoperability problems are reader bugs that +are listed here mostly as warnings to developers of readers. +.IP * 2 +Some readers do not support negative timestamps. +Developers of distributed applications should keep this +in mind if they need to deal with pre-1970 data. +.IP * +Some readers mishandle timestamps before the first +transition that has a nonnegative timestamp. +Readers that do not support negative timestamps are likely to +be more prone to this problem. +.IP * +Some readers mishandle time zone abbreviations like +.q "-08" +that contain +.q "+", +.q "-", +or digits. +.IP * +Some readers mishandle UT offsets that are out of the +traditional range of \*-12 through +12 hours, and so do not +support locations like Kiritimati that are outside this +range. +.IP * +Some readers mishandle UT offsets in the range [\*-3599, \*-1] +seconds from UT, because they integer-divide the offset by +3600 to get 0 and then display the hour part as +.q "+00". +.IP * +Some readers mishandle UT offsets that are not a multiple +of one hour, or of 15 minutes, or of 1 minute. .SH SEE ALSO .BR time (2), .BR localtime (3), -- 2.17.2

1 0

[PROPOSED] * NEWS: Improve recent entries.
by Paul Eggert Oct. 25, 2018

Oct. 25, 2018

--- NEWS | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 4eb313f..943db3e 100644 --- a/NEWS +++ b/NEWS @@ -7,12 +7,14 @@ Unreleased, experimental changes The translator to rearguard format now rewrites the line "Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S" to "Rule Japan 1948 1951 - Sep Sun>=9 1:00 0 S". - This caters to zic before 2007 and to at least one Java-based zi - compiler of uncertain vintage. (Reported by Christos Zoulas.) + This caters to zic before 2007 and to Oracle TZUpdater 2.2.0 + and earlier. (Reported by Christos Zoulas.) Changes to past time zone abbreviations Change HDT to HWT/HPT for WWII-era abbreviations in Hawaii. + This reverts to 2011h, as the abbreviation change in 2011i was + likely inadvertent. Release 2018f - 2018-10-18 00:14:18 -0700 -- 2.17.2

1 0

Bad 32 bit data in 2018f
by Daniel Fischer Oct. 24, 2018

Oct. 24, 2018

Hi, I'm getting bad data in the 32 bit section of some of the compiled files in zoneinfo-leaps. The affected time zones are zones that only transition before 1901, usually from LMT to some UTC offset: Indian/Christmas Indian/Cocos Atlantic/South_Georgia Pacific/Port_Moresby Pacific/Chuuk Pacific/Yap Pacific/Wallis Pacific/Funafuti Pacific/Palau Pacific/Ponape Pacific/Wake Pacific/Pohnpei Pacific/Truk Pacific/Tarawa The files in zoneinfo-leaps contain no transitions, and only the offset used before the transition. This causes applications that only read the 32 bit section to use LMT for these zones. The 64 bit section, and both sections in the zoneinfo version of these files, contain >=2 transitions and offsets (e.g. one real transition and one in 2038). For example, zdump with a break added after /old file/ in localtime.c: $ ./zdump $PWD/TZ/usr/share/zoneinfo*/Atlantic/South_Georgia .../TZ/usr/share/zoneinfo/Atlantic/South_Georgia Tue Oct 23 12:31:33 2018 -02 .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Tue Oct 23 12:04:58 2018 LMT $ ./zdump -V $PWD/TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Sat Jul 1 00:00:00 1972 UT = Fri Jun 30 21:33:52 1972 LMT isdst=0 gmtoff=-8768 .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Sat Jul 1 00:00:01 1972 UT = Fri Jun 30 21:33:52 1972 LMT isdst=0 gmtoff=-8768 [..] .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Sun Jan 1 00:00:27 2017 UT = Sat Dec 31 21:33:52 2016 LMT isdst=0 gmtoff=-8768 I found that before commit 83c119f4d ("Remove Big Bang hack"), the one offset present in the leaps version was the correct one. The structural difference is older; it just didn't affect my application because the offset was the one currently in use. The cause appears to be this sequence of events starting at zic.c /Work around QTBUG-53071/: 1) y2038_boundary-1 transition is added (== INT32_MAX) 2) leap seconds are added to all times, pushing the 2038 transition above INT32_MAX 3) affected zones again only have transition times outside the 32 bit range => timecnt32 is 0 4) because timecnt32 is 0, timei32 is also 0, and the INT32_MIN transition isn't output either 5) because of omittype[defaulttype] = false, the oldest offset is always output regardless of the above The workaround could probably be moved to after the leap seconds are added, especially if it's supposed to apply to the 32 bit leaps files. This will also fix this bug, because the code that determines the 32 bit limits assumes there's at least one time after 1901, and the workaround provides one. (This is why the non-leaps version is correct.) I'm unfortunately not familiar enough with the tz database to suggest a complete fix. Danny -- Daniel Fischer ORACLE Deutschland B.V. & Co. KG, Riesstr. 25, 80992 München - HRA MUC 95603 Komplementaer: ORACLE DE Verw.B.V., Hertogswetering 163/167, 3543 AS Utrecht Geschaeftsfuehrer: Alexander van der Ven, Jan Schultheiss, Val Maher NL

1 0

South Korea timezone history
by Phake Nick Oct. 24, 2018

Oct. 24, 2018

On Korean Wikipedia article for DST https://ko.wikipedia.org/wiki/%EC%9D%BC%EA%B4%91_%EC%A0%88%EC%95%BD_%EC%8B%… , I saw the following lines (with machine translation): >In Korea, the standard meridian of the time was 127° 30' in Tokyo during the period of 1955 to 1960, so it was 30 minutes earlier than it is today. This information is different from what's currently described in tz database and should be investigated. Also, given the example of DST transaction in Japan, it might also worth investigating what did the "00:00[start]-00:00[end]" in Korean DST transaction mean at the time.

1 1

[PROPOSED] * tz-link.html: Update Windows details and links
by Matt Johnson Oct. 23, 2018

Oct. 23, 2018

diff --git a/tz-link.html b/tz-link.html index b5870d3..8593ba6 100644 --- a/tz-link.html +++ b/tz-link.html @@ -524,11 +524,10 @@ clock (intclock)</a> is a clock that displays multiple time zones on under the <abbr>GPL</abbr>.</li> <li>Microsoft Windows 8.1 and later has <code><abbr>tz</abbr></code> data and <abbr>CLDR</abbr> -data (mentioned <a href="#CLDR">below</a>) used by the -<a href="https://en.wikipedia.org/wiki/Windows_Runtime">Windows Runtime</a> / -<a href="https://en.wikipedia.org/wiki/Universal_Windows_Platform">Universal Windows Platform</a> classes -<a href="https://docs.microsoft.com/uwp/api/Windows.Globalization.DateTimeFormatting…"><code>DateTimeFormatter</code></a> and -<a href="https://docs.microsoft.com/uwp/api/windows.globalization.calendar"><code>Calendar</code></a>. +data (mentioned <a href="#CLDR">below</a>) used by +<a href="https://en.wikipedia.org/wiki/Windows_Runtime">Windows Runtime</a> +classes such as <a +href="https://msdn.microsoft.com/en-us/library/windows/apps/windows.globalization…"><code>DateTimeFormatter</code></a>. <a id="System.TimeZoneInfo" href="https://blogs.msdn.microsoft.com/bclteam/2007/06/07/exploring-windows-time-…">Exploring Windows Time Zones with <code>System.TimeZoneInfo</code></a> describes

2 2

Re: [tz] [PROPOSED] Be consistent about WWII abbreviations in Hawaii
by Paul Eggert Oct. 23, 2018

Oct. 23, 2018

On 10/23/18 12:07 PM, Michael H Deckers wrote: > You might want to add HWT and HPT to the list in theory.html as well. Thanks, good catch. Also the NEWS file. I installed the attached.

2 2

DST time zone Amercia/Sao_Paulo
by Júnior Didoné Oct. 23, 2018

Oct. 23, 2018

Greetings, I would like to inform you that DST is *active* for America / Sao_Paulo and Brazil/East Time Zones, since yesterday. However, the *correct* date for activation is *November 4, 2018*, the Brazilian government changed it in February 2018. This is causing errors in Oracle Databases in Amazon Web Services. Please, correct as soon as possible. Thank you, Júnior Didoné

3 2

2018f tzdb released with bug
by Laurenti, Leandro Oct. 23, 2018

Oct. 23, 2018

A/C Mr. Paul Eggert Hi, After several years, the DST start time was changed in Brazil. Until the last year, it was set to start in the 3rd weekend of October. In this year, it will start on November 4th. So, we were instructing our customers to run the tzupdater tool , from oracle, that relies on the "tzdata-latest.tar.gz" file from IANA. However, when the customers are trying to update java, they are getting the following error: https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8212684?filter=allope… Failed: java.lang.Exception: Failed while parsing file 'C:\Users\ME928~1.SYR\AppData\Local\Temp\tz.tmp_5\asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' java.lang.Exception: Failed while parsing file 'C:\Users\ME928~1.SYR\AppData\Local\Temp\tz.tmp_5\asia' on line 1655 'Rule Japan 1948 1951 - S Sat>=8 25:00 0 S' So it seems to be a problem with 2018f version of the tzdb file... It seems the 2018e version is working fine. Not sure if someone from Brazil or any other country already have contacted you... Since this is a very critical problem, we hope this to be fixed asap. Thank you in advance. Best Regards, Leandro Laurenti Support Engineer CA Technologies | Av. Dr. Chucri Zaidan, 1240 26º e 27º andares, Golden Tower | Sao Paulo, SP 04711-130 Office: +80353 | Leandro.Laurenti(a)ca.com <mailto:Leandro.Laurenti@ca.com>[CA]<http://www.ca.com/us/default.aspx>[Twitter]<http://twitter.com/CAInc>[Slideshare]<http://www.slideshare.net/cainc>[Facebook]<https://www.facebook.com/CATechnologies>[YouTube]<http://www.youtube.com/user/catechnologies>[LinkedIn]<http://www.linkedin.com/company/1372?goback=.cps_1244823420724_1>[Google+]<https://plus.google.com/+CATechnologies>[Google+]<http://www.ca.com/us/rss.aspx?intcmp=footernav>

2 6

[PROPOSED] * tz-link.html: Mention TimeZoneConverter and ICU for tz<->windows mappings
by Matt Johnson Oct. 23, 2018

Oct. 23, 2018

diff --git a/tz-link.html b/tz-link.html index b5870d3..f959f93 100644 --- a/tz-link.html +++ b/tz-link.html @@ -541,6 +541,8 @@ Tzid table</a> or <a href="https://unicode.org/repos/cldr/trunk/common/supplemental/windowsZones.xml"><abbr>XML</abbr> file</a> of the <abbr>CLDR</abbr> data maps proprietary zone IDs to <code><abbr>tz</abbr></code> names. +These mappings can be performed programmatically via the <a href="https://github.com/mj1856/TimeZoneConverter">TimeZoneConverter</a> .NET library, +or the ICU Java and C++ libraries mentioned <a href="#ICU">above</a>. <li><a href="https://www.oracle.com/java/index.html">Oracle Java</a> contains a copy of a subset of a recent

1 0

America/Sao_Paulo file.
by Vitor Vieira Andrade Oct. 23, 2018

Oct. 23, 2018

Hi Guis, I've downloaded the tzdata and compiled the Sao_Paulo rulefile. After run the zdump command, the output shows : The daylight saving time should change at Sun 4 Nov, how do i re-compile it on the correct day. Regards, ibm-brasil-100 VITOR VIEIRA ANDRADE IT Specialist - Unix/Linux. E-mail: vitorv(a)br.ibm.com IBM Rua Tutoia 1157 Sao Paulo, SP 04007-900 Brazil

2 1

[PROPOSED] Be consistent about WWII abbreviations in Hawaii
by Paul Eggert Oct. 23, 2018

Oct. 23, 2018

* northamerica (Pacific/Honolulu): Use abbreviations HWT and HPT for consistency with other US abbreviations during World War II. --- northamerica | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/northamerica b/northamerica index 88c0f6f..fb0103f 100644 --- a/northamerica +++ b/northamerica @@ -708,9 +708,7 @@ Zone America/Adak 12:13:22 - LMT 1867 Oct 19 12:44:35 Zone Pacific/Honolulu -10:31:26 - LMT 1896 Jan 13 12:00 -10:30 - HST 1933 Apr 30 2:00 -10:30 1:00 HDT 1933 May 21 12:00 - -10:30 - HST 1942 Feb 9 2:00 - -10:30 1:00 HDT 1945 Sep 30 2:00 - -10:30 - HST 1947 Jun 8 2:00 + -10:30 US H%sT 1947 Jun 8 2:00 -10:00 - HST # Now we turn to US areas that have diverged from the consensus since 1970. -- 2.17.2

1 0

2018e Morocco
by Kiley Walbom Oct. 20, 2018

Oct. 20, 2018

Paul, We are in the process of revamping our extraction programs and noticed an anomaly in Morocco The current rules look like this: v2018e Africa lines 893, 916, and 917 Rule Morocco 2013 max - Oct lastSun 3:00 0 - Rule Morocco 2036 only - Oct 19 3:00 0 - Rule Morocco 2037 only - Oct 4 3:00 0 - Our new program "thinks" there is an overlap in the end dates. After looking at the rules we believe the end date for line 893 should look like this: Rule Morocco 2013 2035 - Oct lastSun 3:00 0 - If the European Commission proposal becomes official, your proposal will fix this issue. Thank you for your time. Kiley

2 1

Chile changes dates for DST from 2019
by Juan Correa Oct. 18, 2018

Oct. 18, 2018

As of moments ago, the Ministry of Energy in Chile has announced the new schema for DST. >From 2019, Chile will end DST (jump from UTC -3 to UTC -4) on the first sunday of April (2019-04-07T03:00:00Z); and will start DST (from UTC -4 to UTC -3) the first sunday of September (2019-09-08T04:00:00Z) Also, the Ministry (Susana Jimenez) announced this decision will stick until 2021; and that Magallanes will keep its own time zone (but there will be meetings to talk about this) Announcement in video (in spanish): https://twitter.com/MinEnergia/status/1029000399129374720 -- Juan Correa Poblete PS Labs (http://www.pslabs.cl)

5 5

Another change on Brazilian DST time
by Fábio Gomes Oct. 18, 2018

Oct. 18, 2018

Hi, The brazilian president just announced a new change on this year DST. It was scheduled to start on November 4th and it was changed to November 18th. How long does it takes to update tzdata with this new information? We, IT professionals, are very upset with this change since most of us had already updated our files. And now we have a very shourt window to apply this new update. Thank you

15 35

[tz-announce] 2018f release of tz code and data available
by Paul Eggert Oct. 18, 2018

Oct. 18, 2018

The 2018f release of the tz code and data is available. It reflects the following changes, which were either circulated on the tz mailing list or are relatively minor technical or administrative changes: Briefly: Volgograd moves from +03 to +04 on 2018-10-28. Fiji ends DST 2019-01-13, not 2019-01-20. Most of Chile changes DST dates, effective 2019-04-06. Changes to future timestamps Volgograd moves from +03 to +04 on 2018-10-28 at 02:00. (Thanks to Alexander Fetisov and Stepan Golosunov.) Fiji ends DST 2019-01-13 instead of the 2019-01-20 previously predicted. (Thanks to Raymond Kumar.) Adjust future predictions accordingly. Most of Chile will end DST on the first Saturday in April at 24:00 mainland time, and resume DST on the first Saturday in September at 24:00 mainland time. The changes are effective from 2019-04-06, and do not affect the Magallanes region modeled by America/Punta_Arenas. (Thanks to Juan Correa and Tim Parenti.) Adjust future predictions accordingly. Changes to past timestamps The 2018-05-05 North Korea 30-minute time zone change took place at 23:30 the previous day, not at 00:00 that day. China's 1988 spring-forward transition was on April 17, not April 10. Its DST transitions in 1986/91 were at 02:00, not 00:00. (Thanks to P Chan.) Fix several issues for Macau before 1992. Macau's pre-1904 LMT was off by 10 s. Macau switched to +08 in 1904 not 1912, and temporarily switched to +09/+10 during World War II. Macau observed DST in 1942/79, not 1961/80, and there were several errors for transition times and dates. (Thanks to P Chan.) The 1948-1951 fallback transitions in Japan were at 25:00 on September's second Saturday, not at 24:00. (Thanks to Phake Nick.) zic turns this into 01:00 on the day after September's second Saturday, which is the best that POSIX or C platforms can do. Incorporate 1940-1949 Asia/Shanghai DST transitions from a 2014 paper by Li Yu, replacing more-questionable data from Shanks. Changes to time zone abbreviations Use "PST" and "PDT" for Philippine time. (Thanks to Paul Goyette.) Changes to code zic now always generates TZif files where time type 0 is used for timestamps before the first transition. This simplifies the reading of TZif files and should not affect behavior of existing TZif readers because the same set of time types is used; only their internal indexes may have changed. This affects only the legacy zones EST5EDT, CST6CDT, MST7MDT, PST8PDT, CET, MET, and EET, which previously used nonzero types for these timestamps. Because of the type 0 change, zic no longer outputs a dummy transition at time -2**59 (before the Big Bang), as clients should no longer need this to handle historical timestamps correctly. This reverts a change introduced in 2013d and shrinks most TZif files by a few bytes. zic now supports negative time-of-day in Rule and Leap lines, e.g., "Rule X min max - Apr lastSun -6:00 1:00 -" means the transition occurs at 18:00 on the Saturday before the last Sunday in April. This behavior was documented in 2018a but the code did not entirely match the documentation. localtime.c no longer requires at least one time type in TZif files that lack transitions or have a POSIX-style TZ string. This future-proofs the code against possible future extensions to the format that would allow TZif files with POSIX-style TZ strings and without transitions or time types. A read-access subscript error in localtime.c has been fixed. It could occur only in TZif files with timecnt == 0, something that does not happen in practice now but could happen in future versions. localtime.c no longer ignores TZif POSIX-style TZ strings that specify only standard time. Instead, these TZ strings now override the default time type for timestamps after the last transition (or for all time stamps if there are no transitions), just as DST strings specifying DST have always done. leapseconds.awk now outputs "#updated" and "#expires" comments, and supports leap seconds at the ends of months other than June and December. (Inspired by suggestions from Chris Woodbury.) Changes to documentation New restrictions: A Rule name must start with a character that is neither an ASCII digit nor "-" nor "+", and an unquoted name should not use characters in the set "!$%&'()*,/:;<=>?@[\]^`{|}~". The latter restriction makes room for future extensions (a possibility noted by Tom Lane). tzfile.5 now documents what time types apply before the first and after the last transition, if any. Documentation now uses the spelling "timezone" for a TZ setting that determines timestamp history, and "time zone" for a geographic region currently sharing the same standard time. The name "TZif" is now used for the tz binary data format. tz-link.htm now mentions the A0 TimeZone Migration utilities. (Thanks to Aldrin Martoq for the link.) Changes to build procedure New 'make' target 'rearguard_tarballs' to build the rearguard tarball only. This is a convenience on platforms that lack lzip if you want to build the rearguard tarball. (Problem reported by Deborah Goldsmith.) tzdata.zi is now more stable from release to release. (Problem noted by Tom Lane.) It is also a bit shorter. tzdata.zi now can contain comment lines documenting configuration information, such as which data format was selected, which input files were used, and how leap seconds are treated. (Problems noted by Lester Caine and Brian Inglis.) If the Makefile defaults are used these comment lines are absent, for backward compatibility. A redistributor intending to alter its copy of the files should also append "-LABEL" to the 'version' file's first line, where "LABEL" identifies the redistributor's change. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2018f.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2018f.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2018f.tar.lz As usual, links to the latest release files are here: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. 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 7c97eb855432c3557a8d84727a685fcd2fdb2bff dated 2018-10-18 00:14:18 -0700 and tagged '2018f' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: d4270918fbd8eb786e6f5cec9f06df6a850bbf1ec278f60ce493b6b7e10e2ad1388383edcd869f07bc78b9d99a123d6f54e74105cdd3d5cb6c98e11d3f043727 tzcode2018f.tar.gz f876729419d45e2b861e564ec7d5940f34fab38c3fedc18852bb800010428c12506f71bde1f20feb23859065118ad4658d97efe89af6f4305cea2beafc515aeb tzdata2018f.tar.gz 4cdc6e2fc3b84c25ba4ac99329cfa7c507bb9be22cab00604bfab65944d225fc605a842e8b0a05e258f6f42eddf8b68273729a211ed78b0172afc2788ae1f29c tzdb-2018f.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlvINAMACgkQ7ZfpDmKq fjSnMRAAr/pLmohlfPzhkcc+Yw4FbpBOYUsj9XeExKd5WDp4nsjgOwLfLJcwT7oo VSp3tiv+jGh+/ZnSZWSTHT/YfBdmRjVmj42FBWZgjYwr70373HGP/vIwHgUrv5Kk wUse5BUX4nwQK0xcuaOzKF5+uUG0MoKDo6sRzrYoS8JMP/mVlLtkZt1GHs99Kkaj Gnn6lyLOTChxrLU2UP1lra0h/t7T/dtTgGHf0biN7onNLYFiRL+La9pJKNVuvljW mjSaPw1Pl+1tCFMo6Rcm8Rkq/cazJaQY2Pdw/CGEvK+a9tjGBf+vvxWhIiLZimAH eygVfg6XCfn7gfjTn6fZHM3+lgGF6W4uQ429jEOR/OUCymb4gOPWB5emSVFms3vy XkHsazZa3UwAD/dzGJ1Y0CXiwggiNqe6xqn41bzqaLgtSg64gK17CIeu42soniZe 5SCXVl45tsURx/z50pQ8Q5I+JK8DvYkkhmP5l8CI6OhYUr8DY+bLdK0+fao8coT9 JXee8U+2ARx7UxgP+yytx+iDzHiRgnnF1is0SkUw9Ksnp61iY9sgpTIuzcr6SOs3 ZLeAT3c6Zmuq+Wikm7u1qVTyR5QcbEmuTspY+4wG9Tn7DrzWnSFj76B1P4+8bENY 28AW/Ca8cqMfcKYv0PVoHhVH3lb1h/zOLV8B06hIWcOErGTGPd4= =9tf8 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlvINAMACgkQ7ZfpDmKq fjRDfg//ciH78cevDN3GyghrxtdY6diUwqaw4qvAngDxeygWS6Hcm8JnExAS7EfZ Mcp1SwDog47Bv+9p11twd0SvdkFPXzrQ4S77ZXIddgTEmZ+a7fVLMtvwn/9w61gL wmEUgSE4yECabGG2mGLMbGaPGmhjCi5Gh3ErmhcmS0xuEvfkyAPcN2KYvLlFt2+H DLvYzYIWhf5O910twzySiIDEpuOsYf60BV9v5/NeEa7Q9kAAytomkhU4WWAeazgU DUFMyWrN9pcn4eWrKFFcRxbXyzSTRdx0E6kgEcVfSjxx75SwNAmWLb5wWarrKV5F MqPRlzVA3favvGNsBGZMdGh2E7Q+qVBGlTxftv2scYX/9I9tP6zMC7/yTl3ys2Hb tNZd5D/99az2VBMxSkaJW8AwwqfHqX5c3GO7p1e5zKy4p5lEMvHtbA1j8GWmy8mQ C1T0pi4JDkq4it/YJyJm8m6eYhUV/v3ftHNPgRIbcoFfMPy+n+wtFAwjY0ml4wKd oUi2x/05u3zoPwGU59aUw09re8LKvbBiu7EuI8p4ZUVaXgkatAqw0T/4jF69hEMx 6X7fY2It1sSg59X5ApWL9JlX8/lK2R5g6MKRqv99HPh60zQ+et8tI6rBY+lX4wx6 2XSOr1OwCNG0l7qLHRx6HVZ7Ce/pX0Mn5TgxonWTKVBh7Jb9Tac= =6cRa -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlvINAUACgkQ7ZfpDmKq fjR7Ag//XMMJj6ZeiWZokr3NEKLNKWwEGo8j/l1XH3tq74KUOINnJqar/d/EPNoi 6mpZHiZ9r03md6TZ/D4Fx2X6lXkdzHnwGiSWY7GzaJSpTqZxzgyWaaZDE9dxGC+5 FB/f96/BSx6oRqZ4dZRBV0vgsjuluo3k9vMotNbUA5lMbIu94QnD4WJ602hNaFbe odI8EXtnr6EQyLBvSFfdbxYLq02cndWPqYTE9cbmNXZ4LnufB/uKmNRYfHIkCOF+ 4ZZNghRbUsC/sUnoSNXaDUV/l43juEPN6RUMKsodOZpAhWyAgRMWw5lbrkCwRMvI dIvpdfynPvQznUuDbq+cyGZefFah9TMPPFZQdGtUejC4hrbWsaP3myTj/jVgvIKC 5qHMb2qD1MebUZtQq2dGZw7/SdyxVmaz8HLINkwrNvfpfGc6+weGmvnPVthPrQxK 4IwQQvzyi4UbPnZLiDuAJZ09OgJ+HgM3CkkIETcUfIXvkYcxFFL4uY+6pHGedoBX KyfPeW3Jc/LivBvy52AOjqYzTjdddQVUymzOQ64rAAzgnBNGdIraCwWEwuBVjHkG hUQFpfjMEkD7kQfxzTxH/LbsT1ifjBBkzxWjeuL8ewhgwykeuwVTeixujH5HKcfx HL2C8e5yY+Zo9eQkyc6YpkUmlnNhsrFLdEoFoAJSrku1dHssw4s= =FA6n -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets, this particular release's data entries are also available in a rearguard-format tarball and signature that does not contain such offsets. This is intended to be a temporary transition aid for these parsers. The URLs are: https://web.cs.ucla.edu/~eggert/tz/release/2018f/tzdata2018f-rearguard.tar.… https://web.cs.ucla.edu/~eggert/tz/release/2018f/tzdata2018f-rearguard.tar.… with the following SHA-512 and GPG checksums: 7c6105cda6bc81217d7740201133d9ccf0d4ca0f5f3e6248fa071c676976c28f06cf7c2240e455d1948f5b2ef5f8e359aca8b5206beddbd6af79c3a7070ba301 tzdata2018f-rearguard.tar.gz -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlvINAMACgkQ7ZfpDmKq fjQM0RAAi56P17pHUDukQ81drgNlRCliqRe1x0047jxCtkrBvIDdJb7lnrTolhrH P78E/f36r4PTAKjGjO9FZvvs61si3YSiHcNdBGzzf41Mhwvbsk14a6ybeU6vRJrj AWUNj/LYg+PK1fUjeY/CrViFWmXPtndPpew9G1cyL3H8HvGQlPm6Ey9JDv6rVVi5 mSkBKXcN5w8VfMzMx2UDLFfRgSnTa4bjbuv/I8HXoAJjtzBR+53G/6oGeXiZ9Fnd hwZa8DbAZ+H4YdsPIdUo/Oz/mU/cfvTZcLkTy7rBciEWk7ylXMddlqdc7+blToga 95eeNGinB6b+8pEpdg0BJTCq7VW4TBjG6W4Zu5RsS3ZJOa8TeMyKVR2S0ZV6zCmN +SvFUHWZ9dqKR7jppxbIsoKSeexpY7WPGJJBwjgZEaIudN0HWok+mw0iLG0U6D2q va3cIEuVG4pitb9uQmuM3hVPuO0Bndxm6ws3hSxvRmTuluJIL4tXErhVJqqZsCJ1 XvqcFlCSD7rtcwP7YzNCKgxzCfMXMvf1Nwfylq8ZWhfaWGk/lBm+eH18zKPHBIe2 OMU9uNxF12KlVNmNknod+AaLTHcXan21vgbR7Syar+fGLofcuPyDOu2frB1FxDaW eotUedxfia9p4gbH5qjMeBHPf2ca8yCf0Dnfmxv174NWVLkOmnE= =OEcz -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

[PROPOSED] * tz-link.html, theory.html: Remove outdated info, fix links and dates.
by Paul Eggert Oct. 18, 2018

Oct. 18, 2018

--- theory.html | 2 +- tz-link.html | 12 +++--------- 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/theory.html b/theory.html index 6e4a14e..8dd58db 100644 --- a/theory.html +++ b/theory.html @@ -1339,7 +1339,7 @@ Sources for time on other planets: Matt Williams, "<a href="https://www.universetoday.com/37481/days-of-the-planets/">How long is a day on the other planets of the solar system?</a>" - (2017-04-27). + (2016-01-20). </li> </ul> </section> diff --git a/tz-link.html b/tz-link.html index eef7b63..8593ba6 100644 --- a/tz-link.html +++ b/tz-link.html @@ -35,8 +35,6 @@ including C Library</a> (used in <a href="https://en.wikipedia.org/wiki/Linux"><abbr>GNU</abbr>/Linux</a>), <a href="https://www.android.com">Android</a>, -<a href="https://developer.mozilla.org/en-US/docs/Mozilla/B2G_OS">B2G -<abbr title="Operating System">OS</abbr></a>, <a href="https://www.freebsd.org">Free<abbr title="Berkeley Software Distribution">BSD</abbr></a>, <a href="https://netbsd.org">Net<abbr>BSD</abbr></a>, @@ -68,8 +66,7 @@ name of the largest city within the region containing the clocks. For example, <code>America/New_York</code> represents most of the <abbr title="United States">US</abbr> eastern time zone; <code>America/Phoenix</code> represents most of Arizona, which -uses mountain time without daylight saving time (<abbr -title="daylight saving time">DST</abbr>); +uses mountain time without daylight saving time (<abbr>DST</abbr>); <code>America/Detroit</code> represents most of Michigan, which uses eastern time but with different <abbr>DST</abbr> rules in 1975; and other entries represent smaller regions like Starke County, @@ -548,7 +545,7 @@ href="https://www.oracle.com/java/index.html">Oracle Java</a> contains a copy of a subset of a recent <code><abbr>tz</abbr></code> database in a Java-specific format.</li> -<li><a href="https://www.relativedata.com/time-zone-master">Time Zone +<li><a href="https://relativedata.com/page/Time-Zone-Master">Time Zone Master</a> is a Microsoft Windows clock program that can automatically download, compile and use <code>tz</code> releases. The Basic version is free.</li> @@ -574,9 +571,6 @@ its own <code>tztab</code>(4) format.</li> <a href="#System.TimeZoneInfo">above</a>.</li> <li><a href="https://www.worldtimeserver.com">World Time Server</a> is another time zone database.</li> -<li><a href="http://tycho.usno.navy.mil/tzones.html">World Time Zones</a> -contains data from the Time Service Department of the -<abbr>US</abbr> Naval Observatory.</li> <li>The <a href="https://www.iata.org/publications/store/Pages/standard-schedules-informatio…">Standard Schedules Information Manual</a> of the @@ -762,7 +756,7 @@ href="ftp://ftp.cs.huji.ac.il/pub/tz/announcements" hreflang="he">announcements (in Hebrew)</a>.</dd> <dt>Italy</dt> <dd>The National Institute of Metrological Research maintains a -<a href="http://www.nanospin.eu/res/tf/ora_legale_i.shtml">table of civil time +<a href="http://oldsite.inrim.it/res/tf/ora_legale_i.shtml">table of civil time (in Italian)</a>.</dd> <dt>Macau</dt> <dd>The Meteorological and Geophysical Bureau maintains a -- 2.17.1

1 0

[TZDB for Delphi] Encountered issue using TBundledTimezone on LINUX
by Jean Frauciel Oct. 17, 2018

Oct. 17, 2018

Hello, I'm working on the development of a software that uses the TZDB for Delphi to deal with the timezones' management, and I'd like to have your opinion about a problem that we are facing. In a procedure, in order to decompose the periods of a timezone, we have to know the timezone's year of a UTC DateTime. To do so, we are using these commands : thisBundledTimezone := TBundledTimeZone.GetTimeZone('America/Los_Angeles'); timeZoneYear := YearOf(IncMinute(aUTCDateTime, Round(thisBundledTimezone.UtcOffset.TotalMinutes))); This is fine if the program is running on Windows, but it crashes on Linux. The error occurs when we're trying to get the UtcOffset. The TBundledTimeZone can't read the FPeriods[I] in the function GetPeriodAndRule. The thing is that FPeriods is a TList that is not typed (with TCompiledPeriod) and Delphi can't use it this way with Linux. We can by the way see a warning when compiling a project that includes TZDB.pas, telling that TList is deprecated. We have solved the problem by modifying the TZDB.pas unit, but it seems weird to have to do this. We are also using the Decomposer.pas unit, but it doesn't have any problem with Linux because it is already working with typed TLists (function Decompose). Do you have any idea about this issue ? You can check the attachment to see our changes. Thank you in advance for your answer, Best regards, Jean FRAUCIEL Développeur Moteur jfrauciel(a)kiamo.fr +33 5 47 48 33 20 <33547483320> | [image: logo web] <http://www.conecteo.fr/> [image: logo linkedin] <https://www.linkedin.com/company/conecteo> <https://twitter.com/Conecteo> <https://www.facebook.com/conecteo> Chers clients et partenaires, rejoignez votre espace communautaire <https://my.kiamo.fr/welcome>

2 1

Palestine 2018 summer time end
by Sharef Mustafa Oct. 17, 2018

Oct. 17, 2018

Hi, As per the Palestinian cabinet decision announced Oct 16th 2018, the summer time for the state of Palestine will end on Sat, Oct 27th 2018 , the clock shall be returned by 60 minutes at 01:00 o'clock (as per the announcement ) Here is a link to the cabinet announcement (in Arabic) : http://palestinecabinet.gov.ps/Website/AR/ViewDetails?ID=42494 Also another link from a local news portal (in Arabic): https://www.maannews.net/Content.aspx?id=964375 Unfortunately I did not find an English source. Please note that this change affects Gaza & Hebron time zones BR Sharef Also

2 1

Wrong spelling of a city in a timezone name
by Igor Oct. 16, 2018

Oct. 16, 2018

Hello. Currently, in your timezone files Ukrainian capital is spelled incorrectly. Kyiv is the correct spelling as decided by UNCSGN (United Nations Conferences on the Standardization of Geographical Names) and UNGEGN (United Nations Group of Experts on Geographical Names)."Kiev" is transliteration from Russian and as Ukraine, which is an independent country, has only one official language, which is Ukrainian, using transliteration from Russian is offending and incorrect. I saw in your files that you understand that Kyiv is correct spelling and you reason that Kiev is more common, alas that argument is wrong. It's only more common because it's been mistakingly used for a long period of time. Ukrainian government is currently running a campaign called Kyiv Not Kiev to raise awareness of international community and it already has results, many companies, like Microsoft, BBC, Google, Facebook and others have already fixed their spelling. I suggest IANA follows this example and fixes this incorrect spelling. Regards, Igor

8 10

Another change on Brazilian DST time
by Raphael Bastos Oct. 16, 2018

Oct. 16, 2018

Yo, Please, abort this change: https://g1.globo.com/politica/noticia/2018/10/15/planalto-informa-que-nao-h… Att, Raphael Bastos aka Tyresix *====================================================* *Wiki Hackstore* - https://wiki.hackstore.com.br <http://wiki.hackstore.com.br/> *Área 31 Hackerspace* - https://www.area31.net.br <http://www.area31.net.br> *====================================================*

1 0

Brazil DST called out
by Rodrigo Freire Oct. 16, 2018

Oct. 16, 2018

Government decided to abandon the announced second DST change. So it will start in November 4. https://g1.globo.com/politica/noticia/2018/10/15/planalto-informa-que-nao-h… - RF Sent from a mobile device

1 0

Ethiopia local time
by admin＠afocha.com Oct. 13, 2018

Oct. 13, 2018

Greetings, Although Ethiopia is officially in East Africa Time (UTC +3:00), the local time used in the country adopts a different system where 6:00 AM is interpreted as 12:00 and socially used as such. People will see a clock with the time at 1:30, and they will say this is 7:30. The local time is used by businesses in the country and by government offices. Everyone generally does this conversion in their heads, so at times, someone who is unfamiliar with this system can end up inadvertently scheduling meetings for the wrong time. This method of time tracking was developed and maintained with the premise of associating the clock's starting point of 12:00 with sunrise, which is roughly taking place around 6:00 AM every day. So East Africa Time - 6:00 is the working time used by the vast majority of Ethiopians. Here's an article discussing this time system: https://www.pri.org/stories/2015-01-30/if-you-have-meeting-ethiopia-you-bet… Is it possible to include Ethiopia's local time system into the time zone database? If so, what are the requirements for submitting a new time zone? Thanks for your consideration. Regards, Khalid Duri

17 48

Re: [tz] Europe/Volgograd change from UTC+3 to UTC+4 from 28oct2018
by Paul Eggert Oct. 11, 2018

Oct. 11, 2018

Alexander Fetisov wrote: > Volgograd region in southern Russia (Europe/Volgograd) change timezone from > UTC+3 to UTC+4 from 28oct2018. > > http://sozd.parliament.gov.ru/bill/452878-7 Thanks for the heads-up and the URL. Its supporting info says the transition occurs at 02:00 that day, the usual practice in that region. That web page says "Находится на рассмотрении" which Google Translate renders as "Is pending", and it later says "Срок представления поправок 10.10.2018" which Google Translate renders as "Term for the submission of amendments 10/10/2018", so it sounds like the bill is under consideration but is not yet law and might be amended. Am I correct? If so, we need to know if and when the proposed change becomes definite. If we're pretty sure the law will go in as-is, we might want to update tzdb before October 10 since this is not much notice for downstream users.

3 9