- tz - lists.iana.org

The rules of DST@Shanghai need some modifications
by Hong Xie Aug. 21, 2018

Aug. 21, 2018

The existing rules of DST@Shanghai is # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S > Rule Shang 1940 only - Jun 3 0:00 1:00 D > Rule Shang 1940 1941 - Oct 1 0:00 0 S > Rule Shang 1941 only - Mar 16 0:00 1:00 D > Rule PRC 1986 only - May 4 0:00 1:00 D > Rule PRC 1986 1991 - Sep Sun>=11 0:00 0 S > Rule PRC 1987 1991 - Apr Sun>=10 0:00 1:00 D There are a news record about the DST in China: http://bjrb.bjd.com.cn/html/2017-08/25/content_169986.htm The accurate hour of DST@China is 02:00. For Example, In 1986, the start time of DST@China is 02:00 May 4 1986. The end time of DST@China is 02:00 Sep 14 1986. So the rule should be modified to: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S > Rule Shang 1940 only - Jun 3 0:00 1:00 D > Rule Shang 1940 1941 - Oct 1 0:00 0 S > Rule Shang 1941 only - Mar 16 0:00 1:00 D > Rule PRC 1986 only - May 4 2:00 1:00 D > Rule PRC 1986 1991 - Sep Sun>=11 2:00 0 S > Rule PRC 1987 1991 - Apr Sun>=10 2:00 1:00 D

2 1

time and cost to reprogram computers for DST in Japan
by Paul Eggert Aug. 20, 2018

Aug. 20, 2018

Earlier this week Mainichi Japan published an article describing some criticism of reintroducing DST to Japan. My favorite quote was this one, abut the time and cost to reprogram computers: "The biggest hurdle in Japan to putting daylight saving time in place is the cost and workload required to adjust computer systems. Professor Tetsutaro Uehara of Ritsumeikan University, a specialist in information systems, estimates that it would take about four years and hundreds of billions of yen to do just that. "'Japan is a country with advanced information technology systems, and computers with timing functions are used everywhere. Many are programmed with Japan time based on the international standard time,' pointed out Uehara. 'Software would have to be rewritten to introduce summer time. Such work would take about four years and cost hundreds of billions of yen. It is crazy to attempt to put it in place by the 2020 Games,' said the bewildered professor." My source: Nakagawa S, Hatta K. Daylight saving time causes more trouble than benefits, say critics. The Mainichi. 2018-08-12. https://mainichi.jp/english/articles/20180812/p2a/00m/0na/010000c

6 8

Time zones in the news
by Arthur David Olson Aug. 13, 2018

Aug. 13, 2018

"Trump’s diplomatic learning curve: Time zones, ‘Nambia’ and ‘Nipple’" https://www.politico.com/story/2018/08/13/trump-world-knowledge-diplomatic-… @dashdashado

1 0

2-hour DST during 2020 Tokyo Olympics?
by Paul Eggert Aug. 8, 2018

Aug. 8, 2018

Prompted by the recent deadly heat wave in Japan, Prime Minister Shinzo Abe met yesterday with the president of the 2020 Tokyo Olympic organizing committee, and discussed whether to introduce one or two hours of daylight saving time during the 2020 Olympics to help beat that summer's heat. Although Japan's 2020 Olympics bid said that Tokyo's July/August climate has "many days of mild and sunny weather" and is "an ideal climate for athletes to perform at their best", in reality a Tokyo summer's heat and humidity can be brutal: summer temperatures regularly get to 35°C (95°F) and last week peaked at 41°C (106°F). The International Olympic Committee has agreed to allow staging the marathon at 07:00 to beat the heat. "Why not 05:00? the sun will already be up then," Tokyo residents may be thinking. Apparently the recent heat wave has caused organizers to think the same thing, as a 2-hour DST would advance the event's effective starting time to 05:00 by the sun while still keeping it nominally at 07:00. Although the 1964 Tokyo Games were held in October to avoid heat, this was before the Olympics schedule was subject to the scheduling demands of broadcasters and sponsors. The 2016 Rio de Janeiro Summer Olympics ratings were down 9% from 2012 (including digital streaming) and event dates will be an important factor in the 2020 ratings. Although a 2-hour DST would presumably affect attendance and ratings only in Japan, that alone is a significant concern for the event's organizers. My sources: Tokyo weighs daylight saving time for Olympics as heat wave incinerates weather descriptions used for 2020 Games bid. Japan Times. 2018-07-28. https://www.japantimes.co.jp/news/2018/07/28/national/tokyo-weighs-daylight… OLYMPICS/2020 Tokyo organizers consider daylight saving to beat heat. Asahi Shimbun. 2018-07-28. http://www.asahi.com/ajw/articles/AJ201807280009.html

6 7

California may vote on permanent daylight time
by Steve Allen Aug. 5, 2018

Aug. 5, 2018

The legislators have approved a bill to allow California voters to decide whether the state should move to permanent daylight time. The governor now has less than 12 days to veto. Even if voters say yes, federal approval will be required. http://www.santacruzsentinel.com/technology/20180622/year-round-daylight-sa… -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

7 7

Proposed Volgograd time zone change
by Stepan Golosunov Aug. 5, 2018

Aug. 5, 2018

There is currently a bill to change time in Volgograd oblast from Moscow time to Moscow+1. The bill is the result of a local referendum, so it will likely be passed into law. That would require changing Europe/Volgograd from UTC+3 to UTC+4. Proposed change date (2018-10-28) though looks too optimistic (publication of the law before that date while still possible is unlikely) and will likely be amended. http://sozd.parliament.gov.ru/bill/452878-7 Other news: The bill to reintroduce Julian calendar awaits its rejection for some time already: http://sozd.parliament.gov.ru/bill/194304-7 The bill to move clocks 1 hour forward ("permanent summer time") throughout Russia was recently recommended to be rejected: http://sozd.parliament.gov.ru/bill/383137-7 Russian Railways announced that they are changing time displayed on station clocks, timetables and tickets from Moscow time to local time: http://eng.rzd.ru/newse/public/en?STRUCTURE_ID=15&layer_id=4839&id=107332

1 0

Incorrect Time Zone Data for American/Grand_Turk
by Robert MacGrogan Aug. 4, 2018

Aug. 4, 2018

Hi there. It looks to me like the time zone data for America/Grand_Turk is incorrect in 2018e version of the database. Turks and Caicos switched to supporting daylight savings time in March of 2018. So in summer the correct time for America/Ground_Turk should be GMT -4 and then back to GMT -5 again in the fall. The current database returns times for summer of 2018 as GMT -5, which is incorrect. Thank you. -- Rob MacGrogan | Director of Software Development rmacgrogan(a)flightbridge.com <rmacgrogan(a)flightbridge.com> 850-509-6158 [image: FlightBridge] <http://www.flightbridge.com/> FlightBridge, Inc. 530 Means Street, Suite 405 Atlanta, GA 30318 www.flightbridge.com

7 19

[PROPOSED] One line per metadatum in tzdata.zi
by Paul Eggert July 31, 2018

July 31, 2018

With the new metadata, version lines could be long. E.g., 'make DATAFORM=rearguard REDO=posix_only PACKRATDATA=backzone BACKWARD=' could generate a tzdata.zi line like this: # version 2018e-57-gba7f088,dataform=rearguard,redo=posix_only,ddeps=(backzone,!backward) which is quite a mouthful and is stretching the definition of "version". To avoid the problem, output a separate comment line for each metadata component instead, like this: # version 2018e-57-gba7f088 # dataform rearguard # redo posix_only # ddeps backzone !backward This is easier to read and to parse and should scale better if we add more metadata later. * NEWS: Mention this. * zishrink.awk: Output a separate line for each metadatum. 2018-07-21 Paul Eggert <eggert(a)cs.ucla.edu> Use space, not comma, in tzdata.zi "# version" * zishrink.awk: Use space instead of comma to separate original version string from auxiliary configuration information. This saves two bytes and (more important) is easier for humans to read. --- NEWS | 16 ++++++++-------- zishrink.awk | 20 ++++++++++---------- 2 files changed, 18 insertions(+), 18 deletions(-) diff --git a/NEWS b/NEWS index 413d649..a3fc622 100644 --- a/NEWS +++ b/NEWS @@ -92,14 +92,14 @@ Unreleased, experimental changes tzdata.zi is now more stable from release to release. (Problem noted by Tom Lane.) It is also a bit shorter. - tzdata.zi's version comment now contains information about 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, no text is - appended to the version comment, for backward compatibility. - A redistributor intending to alter its copy of the files should - also append "-SOMETHING" to the 'version' file's first line, where - "SOMETHING" identifies what was changed. + 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. Release 2018e - 2018-05-01 23:42:51 -0700 diff --git a/zishrink.awk b/zishrink.awk index 162e515..74e0de9 100644 --- a/zishrink.awk +++ b/zishrink.awk @@ -287,30 +287,30 @@ BEGIN { # that affect the output of this script, you should append '-SOMETHING' # to the contents of 'version', where SOMETHING identifies what was changed. - if (dataform != "main") { - version = version ",dataform=" dataform - } - if (redo != "posix_right") { - version = version ",redo=" redo - } ndeps = split(deps, dep) ddeps = "" for (i = 1; i <= ndeps; i++) { if (default_dep[dep[i]]) { default_dep[dep[i]]++ } else { - ddeps = ddeps "," dep[i] + ddeps = ddeps " " dep[i] } } for (d in default_dep) { if (default_dep[d] == 1) { - ddeps = ddeps ",!" d + ddeps = ddeps " !" d } } + print "# version", version + if (dataform != "main") { + print "# dataform", dataform + } + if (redo != "posix_right") { + print "# redo " redo + } if (ddeps) { - version = version ",ddeps=(" substr(ddeps, 2) ")" + print "# ddeps" ddeps } - print "# version", version print "# This zic input file is in the public domain." prehash_rule_names() -- 2.7.4

1 0

Getting current tzdb version in use
by Aldrin Martoq Ahumada July 26, 2018

July 26, 2018

Hi, I was looking for a reliable way to get the current tzdb version (something like 2018e), but it seems it doesn’t exists yet. A couple of examples: - In Mac OS 10.13.6, there is a /usr/share/zoneinfo/+VERSION that says 2018c. - In one of my updated Ubuntu 16.04 servers, the only reliable way is to do a dpkg -s tzdata | grep ^Version, and guess the real version from the string “Version: 2017c-0ubuntu0.16.04" - The “tzinfo” ruby library can get the version only if it uses its own version of tzdata, if it uses the OS files, there is no string version. Knowing the current tzdb version is essential for automating timezone updates. I think an appropriate place to put that string is in the binary TZif file itself, so tools like tzinfo can get the current version *of the current timezone in use*, instead of looking some random file like +VERSION in a random directory/folder. Is there any chances for this to happen? Or any other suggestion? Aldrin.

18 51

Re: [tz] Celinograd (Astana)
by Paul Eggert July 20, 2018

July 20, 2018

Marat Nigametzianov wrote: > https://ru.m.wikipedia.org/wiki/Время_в_Казахстане Generally we prefer primary sources, as Wikipedia is less reliable (anybody can edit it). > And this is link to order from 1956 about timezone in USSR > http://astro.uni-altai.ru/~orion/blog/2011/11/novyie-granitsyi-chasovyih-po… Thanks, that source should be quite helpful. Proposed patch attached. This is to commentary only. > Where is a two part of kazahstan and celinograd (astana) is in eastern part > of it, so it always have to be +6 Currently Astana is covered by Asia/Almaty, which already says that the region was at UT +06 from 1930-06-21 until 1981-04-01. So I'm afraid that I don't see why a change to tzdata is needed (other than to commentary).

2 2