- tz - lists.iana.org

EU Public Consultation on summertime arrangements
by John Wilcock Aug. 29, 2018

Aug. 29, 2018

https://ec.europa.eu/info/consultations/2018-summertime-arrangements_en > > Objective of the consultation > > Following a number of requests from citizens, from the European > Parliament, and from certain EU Member States, the Commission has > decided to investigate the functioning of the current EU summertime > arrangements and to assess whether or not they should be changed. > > In this context, the Commission is interested in gathering the views > of European citizens, stakeholders and Member States on the current EU > summertime arrangements and on any potential change to those arrangements. >

9 39

Fwd: TZDB Questions
by Paul Eggert Aug. 29, 2018

Aug. 29, 2018

[Forwarded with permission.] -------- Forwarded Message -------- Subject: TZDB Questions Date: Mon, 27 Aug 2018 17:52:53 -0700 From: Mikey Schott <maschott(a)gmail.com> To: eggert(a)cs.ucla.edu Hello, Dr. Eggert. First let me express my thanks to you for all of the time and energy you have put into the upkeep of the time zone database. I appreciate all of the thought and detail that goes into the decisions regarding each zone. I've been working extensively with the time zone database over the past month to identify a list of currently unique time zones for use in a front-end web application. I'd be happy to share the details of my work if you are curious, but since its purpose is tangential to that of the time zone database, I'll leave them out of this email. The reason I'm writing is because after working so closely with the data, I had a few questions I was hoping you could answer for me. I have more or less completed the work I was doing, so these questions come more from curiosity than necessity. 1. Has there been any consideration to move the source data into a more structured format like csv, xml, or json? I realize I'm probably in the minority here in terms of people who would find this useful. 2. The latest zone entry for some zones that no longer use dst still point to dst rules, e.g. Asia/Tokyo and the Japan rule set even though dst is no longer used in Japan . Is there a reason why some non-dst zones use this method where they point to an outdated rule set whereas most non-dst zones use no rule set (i.e. rule = '-')? 3. I've noticed that some zones just use a shortened version of their offset for their format, whereas timeanddate.com gives them a more descriptive format (e.g. Europe/Volgograd uses MSK vs. +03). Is there a reason for the discrepancy? Does the time zone database error on the side of caution here? 4. I believe that one of the primary purposes of the Link zones is to ensure that there is a zone that covers every country. Is there a specific list or source that the time zone database uses to decide the list of countries that are covered? I noticed that Bouvet Island (BV) and Heard and McDonald Islands (HM) are not included despite having ISO-3166-2 country codes. (Although both have a population of 0, so it hardly qualifies as an oversight.) 5. Do you have a favorite time zone? I've become quite fond of Antarctica/Troll both for its name and its unique offset. Thanks again for all of your work on the database. I've signed up for the mailing list so I can keep up to date. -Mikey

3 3

Re: [tz] TZDB Questions
by Mikey Schott Aug. 28, 2018

Aug. 28, 2018

Great. Thanks for all the answers.

1 0

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. 19, 2018

Aug. 19, 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. 3, 2018

Aug. 3, 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

Getting current tzdb version in use
by Paul Eggert July 20, 2018

July 20, 2018

On 07/19/2018 08:50 AM, lester(a)lsces.co.uk wrote: > The bottom line is that currently we have no way of knowing just what data is > being supplied. Even if the data matches the raw tz version, it may or may not > include the pre-1970 <tel:1970> data archived to backzone. Yes, and this is partly why I have resisted putting version information into the installed files. Version info is typically not available unless you've merely cloned the development Git repository and have made no change to the data or to the 'make' parameters that select or alter the data, a situation that is reasonably rare in practice. It would take quite a bit of effort to get reliable version information in real installations, and nobody knows exactly what would be entailed in that effort. Since many people have requested version info I had compromised by putting a version string into tzdata.zi as a sort of experiment. The experiment has clearly failed so far. That being said, we can improve things a bit by putting into tzdata.zi information about whether the file 'backward' was used, as well as whether the (dicey) file 'backzone' and the (obsolete) file 'pacificnew' were used. We can also record whether the rearguard (or vanguard) data format was selected. Proposed patch attached. Harold, if you're changing your C++ library to look for "unknown", this patch might append some stuff to that "unknown" string.

2 2

rearguard
by Lord Buddha July 18, 2018

July 18, 2018

This would be so much easier (for me;) ) if all data forms were published by IANA. $ awk -v DATAFORM=vanguard -f ziguard.awk africa antarctica asia australasia europe northamerica southamerica etcetera systemv factory backward *malloc(): memory corruptionAborted (core dumped)* On Ubuntu 18.04 trying to get files in rearguard format so I can patch Java & JodaTime.... Need to patch as we need the Fiji change now.

3 4

[PATCH] Give title lines to many files lacking them
by Paul Eggert July 16, 2018

July 16, 2018

--- Makefile | 2 ++ africa | 2 ++ antarctica | 2 ++ asia | 2 ++ australasia | 2 ++ backward | 2 ++ difftime.c | 2 ++ etcetera | 2 ++ europe | 2 ++ factory | 2 ++ localtime.c | 2 ++ newstrftime.3 | 2 ++ northamerica | 2 ++ pacificnew | 2 ++ private.h | 2 ++ southamerica | 2 ++ systemv | 2 ++ tzfile.h | 2 ++ tzselect.ksh | 5 ++--- workman.sh | 1 + yearistype.sh | 1 + zdump.c | 2 ++ zic.c | 2 ++ zoneinfo2tdf.pl | 1 + 24 files changed, 45 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 9e3b8f9..d01bb9a 100644 --- a/Makefile +++ b/Makefile @@ -1,3 +1,5 @@ +# Make and install tzdb code and data. + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/africa b/africa index eb7f8ae..131330e 100644 --- a/africa +++ b/africa @@ -1,3 +1,5 @@ +# tzdb data for Africa and environs + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/antarctica b/antarctica index 866cf4f..1dd9b00 100644 --- a/antarctica +++ b/antarctica @@ -1,3 +1,5 @@ +# tzdb data for Antarctica and environs + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/asia b/asia index 810ef47..7166380 100644 --- a/asia +++ b/asia @@ -1,3 +1,5 @@ +# tzdb data for Asia and environs + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/australasia b/australasia index 938c591..87ba620 100644 --- a/australasia +++ b/australasia @@ -1,3 +1,5 @@ +# tzdb data for Australasia and environs, and for much of the Pacific + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/backward b/backward index a455044..51e10f4 100644 --- a/backward +++ b/backward @@ -1,3 +1,5 @@ +# tzdb links for backward compatibility + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/difftime.c b/difftime.c index 856234a..7b96927 100644 --- a/difftime.c +++ b/difftime.c @@ -1,3 +1,5 @@ +/* Return the difference between two timestamps. */ + /* ** This file is in the public domain, so clarified as of ** 1996-06-05 by Arthur David Olson. diff --git a/etcetera b/etcetera index 1a59630..91ded93 100644 --- a/etcetera +++ b/etcetera @@ -1,3 +1,5 @@ +# tzdb data for ships at sea and other miscellany + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/europe b/europe index 8a8f8f9..a5feb59 100644 --- a/europe +++ b/europe @@ -1,3 +1,5 @@ +# tzdb data for Europe and environs + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/factory b/factory index 5f0573d..d4e7659 100644 --- a/factory +++ b/factory @@ -1,3 +1,5 @@ +# tzdb data for noncommittal factory settings + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/localtime.c b/localtime.c index b217865..6b45254 100644 --- a/localtime.c +++ b/localtime.c @@ -1,3 +1,5 @@ +/* Convert timestamp from time_t to struct tm. */ + /* ** This file is in the public domain, so clarified as of ** 1996-06-05 by Arthur David Olson. diff --git a/newstrftime.3 b/newstrftime.3 index 1fd80df..eee503e 100644 --- a/newstrftime.3 +++ b/newstrftime.3 @@ -1,3 +1,5 @@ +.\" strftime man page +.\" .\" Based on the UCB file whose corrected copyright information appears below. .\" Copyright 1989, 1991 The Regents of the University of California. .\" All rights reserved. diff --git a/northamerica b/northamerica index 06db1a8..ffbda74 100644 --- a/northamerica +++ b/northamerica @@ -1,3 +1,5 @@ +# tzdb data for North and Central America and environs + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/pacificnew b/pacificnew index 7349434..0e6cf07 100644 --- a/pacificnew +++ b/pacificnew @@ -1,3 +1,5 @@ +# tzdb data for proposed US election time (this file is obsolete) + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/private.h b/private.h index 641f905..1ead147 100644 --- a/private.h +++ b/private.h @@ -1,3 +1,5 @@ +/* Private header for tzdb code. */ + #ifndef PRIVATE_H #define PRIVATE_H diff --git a/southamerica b/southamerica index aab355c..67562f2 100644 --- a/southamerica +++ b/southamerica @@ -1,3 +1,5 @@ +# tzdb data for South America and environs + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/systemv b/systemv index d9e2995..24c8f64 100644 --- a/systemv +++ b/systemv @@ -1,3 +1,5 @@ +# tzdb data for System V rules (this file is obsolete) + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/tzfile.h b/tzfile.h index f7f5caf..27a38cc 100644 --- a/tzfile.h +++ b/tzfile.h @@ -1,3 +1,5 @@ +/* Layout and location of TZif files. */ + #ifndef TZFILE_H #define TZFILE_H diff --git a/tzselect.ksh b/tzselect.ksh index f7d8154..18fce27 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -1,12 +1,11 @@ #!/bin/bash +# Ask the user about the time zone, and output the resulting TZ value to stdout. +# Interact with the user via stderr and stdin. PKGVERSION='(tzcode) ' TZVERSION=see_Makefile REPORT_BUGS_TO=tz(a)iana.org -# Ask the user about the time zone, and output the resulting TZ value to stdout. -# Interact with the user via stderr and stdin. - # Contributed by Paul Eggert. This file is in the public domain. # Porting notes: diff --git a/workman.sh b/workman.sh index 4b3b64a..8fb18a4 100644 --- a/workman.sh +++ b/workman.sh @@ -1,4 +1,5 @@ #! /bin/sh +# Convert manual page troff stdin to formatted .txt stdout. # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/yearistype.sh b/yearistype.sh index dfdcdf0..d674175 100644 --- a/yearistype.sh +++ b/yearistype.sh @@ -1,4 +1,5 @@ #! /bin/sh +: 'Determine whether year is of appropriate type (this file is obsolete).' : 'This file is in the public domain, so clarified as of' : '2006-07-17 by Arthur David Olson.' diff --git a/zdump.c b/zdump.c index 4c61f58..608f288 100644 --- a/zdump.c +++ b/zdump.c @@ -1,3 +1,5 @@ +/* Dump time zone data in a textual format. */ + /* ** This file is in the public domain, so clarified as of ** 2009-05-17 by Arthur David Olson. diff --git a/zic.c b/zic.c index 88153db..9d455b5 100644 --- a/zic.c +++ b/zic.c @@ -1,3 +1,5 @@ +/* Compile .zi time zone data into TZif binary files. */ + /* ** This file is in the public domain, so clarified as of ** 2006-07-17 by Arthur David Olson. diff --git a/zoneinfo2tdf.pl b/zoneinfo2tdf.pl index e05ec01..c8c5591 100755 --- a/zoneinfo2tdf.pl +++ b/zoneinfo2tdf.pl @@ -1,4 +1,5 @@ #! /usr/bin/perl -w +# Summarize .zi input in a .zi-like format. # Courtesy Ken Pizzini. -- 2.7.4

1 0

Celinograd (Astana)
by Marat Nigametzianov July 16, 2018

July 16, 2018

Celinograd (Astana) in 1969 must be +6 UTC not +5 https://www.worldtimezone.com/dst_news/dst_news_ussr-map-1970.html -- Nigametzianov Marat ____________________________________________________________________________ 8 926 568-93-08, ppmarat(a)gmail.com

2 1

Fiji DST 2018/19
by Raymond Kumar July 15, 2018

July 15, 2018

Hi Paul, There is a DST time change in Fiji island from November 4th. http://www.fijitimes.com/government-approves-2018-daylight-saving/ The attached order states: Members of the public are advised to move their clocks one hour ahead at 2am on Sunday November 4. The daylight saving period will end at 3am on Sunday January 13, 2019. Fiji rules in tzdata2018e.tar.gz: There is a need to change the NON DST time from 14th Jan to 13th Jan. Can a new tzdata be generated for Fiji Islands. Rule Fiji 2014 max - Nov Sun>=1 2:00 1:00 - Rule Fiji 2015 max - Jan Sun>=14 3:00 0 - Thanks, Raymond Kumar Head of Billing & Products +679-7015315 ________________________________ Notice of Confidentiality: The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system.

4 9

Re: [tz] EU Public Consultation on summertime arrangements
by Pierpaolo Bernardi July 11, 2018

July 11, 2018

Not time related. Only for pedantry sake: at the border between San Marino and Italy there *are* controls, by the Italian police. This is due to different tax laws in the two countries, which would make shopping in San Marino very convenient for Italy residents, if they weren't controlled when exiting from RSM for any good bought in RSM, and forced to pay due taxes. FWIW Il giorno 11 luglio 2018, alle ore 09:08, John Wilcock <john(a)tradoc.fr> ha scritto: Le 11/07/2018 à 00:05, Brian Inglis a écrit : > Most people are probably not that aware of European geography [...] Taking the world as a whole, you are no doubt correct, but most of the people at the EU who will be reading Paul's submission will be perfectly aware of European geography! >> I don't see the relevance of "Schengen area" - all current and potential >> Schengen area countries are either EU or EEA/EFTA members. > The Schengen Area also includes non-EU/EEA/EFTA countries Monaco, San Marino, > and the Vatican, which have not signed the Schengen agreement, but have no > borders, so are de facto included. While these three countries are indeed de facto within the Schengen area due to the lack of border *controls* — they do still have borders ;-) — it still seems (at least to me as a European) very odd to mention Schengen purely in order to include its *non*-signatories, especially as the next item in the list is in any case the all-inclusive "other countries not in the EU". -- John

1 0

(no subject)
by Ashish Ahmed July 10, 2018

July 10, 2018

Confirm

1 0

tz-art suggestion
by Steve Jones July 6, 2018

July 6, 2018

Not sure how this was missed, having passed its third birthday, but probably deserves a mention in tz-art: "Daylight Saving Time: How is this still a thing?" https://www.youtube.com/watch?v=br0NW9ufUUw Regards, Steve Jones [image: Emacs!]

3 2

strftime and nonnormalized dates/times
by scs＠eskimo.com July 5, 2018

July 5, 2018

I have a question about the strftime function. This is not related to time zones per se, but there are a lot of date/time programming experts here, and of course there's a reference implementation of strftime in tzcode. [Full disclosure: I am posting the same question to StackOverflow: https://stackoverflow.com/questions/51145727/ .] Most definitions of the %H, %M, and %S specifiers (including those in the ANSI/ISO C Standards) contain language like %H is replaced by the hour (24-hour clock) as a decimal number (00-23). Now, that little notation "(00-23)" at the end tells you the range of numbers you're going to see *if the struct tm you're printing was just created by localtime or gmtime*. My question concerns the presence or absence of a requirement that the struct tm being referenced by strftime *must* have been one just generated by localtime or gmtime. I don't think there's such a requirement, but if there isn't, those notations "(00-23)" and "(00-59)" don't really have any normative implications for strftime -- they're more of a misplaced requirement on the values generated by localtime and gmtime. But if strftime doesn't restrict the ranges of the various struct tm fields to their "normal" values, it makes me wonder how much latitude a push-the-boundaries programmer actually has when calling strftime. Are the values as unlimited as they are when calling, say, mktime? To make the question more concrete, it came to me when I found myself writing this code: time_t dt = t2 - t1; struct tm *tmp = gmtime(&dt); if(dt > 86400) tmp->tm_hour += dt / 86400 * 24; strftime(etbuf, sizeof(etbuf), "elapsed: %H:%M:%S", tmp); That is, I'm subtracting two times, and letting gmtime and strftime convert the difference to HH:MM:SS format for me. But if the time delta was more than a day, I'm not printing it as days; I'm just lumping it in with the hours (which, it's true, might end up being a very large number if there were months or years between t1 and t2). So, language lawyer question: Is this legal and portable? When calling strftime, are tm_hour, tm_min, and the rest limited to their normal ranges, or not? (Yes, I've tried it, and nonnormalized values work -- not at all surprisingly -- as expected under the popular implementations, but that's not the question.)

4 6

African Timezones
by Robin Roos July 4, 2018

July 4, 2018

Hi Folks, I am using a Java platform (hosted on Linux and on Windows) in which I find some expected timezones to be missing. I write to enquire whether they are defined at IANA and, if not, whether they can be added. The timezones in question are as follows: Africa/Praia (capital city of Cabo Verde, also known also as Cape Verde) = UTC-1 CVT (Cabo Verde Time) = UTC-1 (one hour West of Greenwich) WAT (West Africa Time) = UTC+1 (one hour East of Greenwich) CAT (Central Africa Time) = UTC+2 (two hours East of Greenwich) EAT (East Africa Time) = UTC+3 (three hours East of Greenwich) My source for this information is: https://www.worldtimezone.com/time-africa24.php Many thanks, Robin.

2 2

"time zone" vs "timezone" in documentation
by Paul Eggert July 4, 2018

July 4, 2018

[I am cc'ing this to the tz mailing list (and changing the subject line) to give tz readers a heads-up about the terminology issue. The question here is: should tzdb man pages say "time zone" or "timezone"? For context please see Michael Kerrisk's email <https://marc.info/?m=152964652828320>, which says: > When I inherited the project, the pages used a mixture of "time zone" > and "timezone", with the former predominant. I nevertheless > standardized on the latter, and although I don't recall for sure, I > suspect it was because that is the spelling used in POSIX. (As an > aside, there's an argument that--because POSIX--tzdb might want to > consider switching spellings.) I'm not religious about the particular > choice (although I have naturally now got used to the particular > choice I made some years ago), but I did make that choice because I > want consistency within the project, and I'm reluctant to introduce > inconsistency. and my response <https://marc.info/?m=152964676331902>, which says: > I deferred to POSIX for "timestamp" versus "time stamp", but > "timezone" is a bridge too far for me. ] On second thought, perhaps I was too hasty. We could distinguish "time zone" in the usual English-language sense (a set of geographic locations that currently share the same standard time offset from UTC) from "timezone" in the POSIX sense (a history and predicted future of UTC offsets, abbreviations and isdst flags). If so, the tzdb documentation could be more careful about using "time zone" for the former and "timezone" for the latter, and this would make for fewer changes to the GNU/Linux man-pages for tzdb. I can look into this and propose an updated set of tzdb-related patches accordingly. If I were designing the terminology from scratch, I wouldn't specify two nearly-identical phrases "time zone" and "timezone" to mean such different things. However, the phrases do have the advantage of existing practice (common English usage and POSIX, respectively).

9 11

[PROPOSED] * tz-link.html (Precision timekeeping): Mention Huygens.
by Paul Eggert June 29, 2018

June 29, 2018

--- tz-link.html | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tz-link.html b/tz-link.html index 548fbba..7ed1efd 100644 --- a/tz-link.html +++ b/tz-link.html @@ -813,11 +813,15 @@ title="Network Time Protocol">NTP</abbr>: The Network Time Protocol</a> (Internet <abbr>RFC</abbr> 5905) discusses how to synchronize clocks of Internet hosts.</li> +<li>The <a href="https://www.usenix.org/system/files/conference/nsdi18/nsdi18-geng.pdf"><font style="font-variant: small-caps">Huygens</font></a> +family of software algorithms can achieve accuracy to a few tens of +nanoseconds in scalable server farms without special hardware.</li> <li>The <a href="https://www.nist.gov/intelligent-systems-division/ieee-1588">Precision Time Protocol</a> (<abbr title="Institute of Electrical and Electronics Engineers">IEEE</abbr> 1588) -can achieve submicrosecond clock accuracy on a local area network.</li> +can achieve submicrosecond clock accuracy on a local area network +with special-purpose hardware.</li> <li><a href="https://tools.ietf.org/html/rfc4833">Timezone Options for <abbr title="Dynamic Host Configuration Protocol">DHCP</abbr></a> -- 2.17.1

1 0