- tz - lists.iana.org

[PATCH 1/1] * LICENSE: New file.
by James Knight Dec. 8, 2015

Dec. 8, 2015

Adding a license-specific file to aid in package management and other possible use cases. Signed-off-by: James Knight <james.knight(a)rockwellcollins.com> diff -Naur tz_a/LICENSE tz_b/LICENSE --- tz_a/LICENSE 1969-12-31 19:00:00.000000000 -0500 +++ tz_b/LICENSE 2015-10-23 17:59:01.702710278 -0400 @@ -0,0 +1,21 @@ +Unless otherwise specified, all files in the tz code and data are in +the public domain, so clarified as of 2009-05-17 by Arthur David Olson. +The few exceptions are code derived from BSD, which uses the BSD license. + +date.c and strftime.c: +---------------------- +Copyright (c) 1985, 1987, 1988 The Regents of the University of California. +All rights reserved. + +Redistribution and use in source and binary forms are permitted +provided that the above copyright notice and this paragraph are +duplicated in all such forms and that any documentation, +advertising materials, and other materials related to such +distribution and use acknowledge that the software was developed +by the University of California, Berkeley. The name of the +University may not be used to endorse or promote products derived +from this software without specific prior written permission. +THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR +IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. +

2 1

CCTZ time zone library for C++ from Google
by Tim Parenti Dec. 8, 2015

Dec. 8, 2015

FYI, last month, Google released and open-sourced cctz <https://github.com/google/cctz>, a new time zone library for C++. My favorite quote from the announcement <http://google-opensource.blogspot.com/2015/09/introducing-cctz-simple-time-…> on their Open Source Blog: > *"Time zones are logical and easy to use." —no one ever* -- Tim Parenti

6 9

Re: [tz] Question about historical TZData for North Carolina
by Paul Eggert Dec. 7, 2015

Dec. 7, 2015

On 12/07/2015 04:25 AM, Clifford Ribaudo wrote: > http://ncpedia.org/time-zones > > The relevant section of the article states that: > > On 28 Sept. 1947 North Carolina adopted Eastern Standard Time statewide. > > During World War I, North Carolina adopted Daylight Time for the periods 31 Mar.-27 Oct. 1918 and 30 Mar.-26 Oct. 1919. Between 1 Aug. 1941 and 9 Feb. 1942, state offices operated on Daylight Time; from 9 Feb. 1942 to 30 Sept. 1945, North Carolina implemented what President Franklin D. Roosevelt called "War Time." From 1946 to 1965 North Carolina did not observe Daylight Time, but since 1966 the state has followed the national schedule. > > So in summary that means we have: > > 1) Sep 28 1947 statewide adoption of ET > 2) Mar 31 - Oct 27 1918 Adopted Daylight Time > 3) Mar 30 - Oct 26 1919 Adopted Daylight Time > 4) Feb 9 1942 - Sep 30 1945 Adopted War Time > 5) 1946 - 1965 Daylight time NOT observed > 6) 1966 - Entire state adopts national schedule for Daylight time. > > So I would propose that this data be added to an America/North_Carolina entry in backzone That's useful info. Let me try to summarize what work would need to be done to get this in (and this may help to explain why it hasn't been done yet....). First, that source is better than nothing, but it has real problems. First, it cites secondary sources (Doane is an old astrology book if I'm not mistaken, and the DOT source is also secondary), and these secondary sources are often in error. Second, it summarizes the secondary sources without giving full details, e.g., it doesn't say which part of North Carolina formerly observed Central Time, and it doesn't give the times that switchovers occurred. Someone should read the secondary sources directly, or better yet, read the primary sources that they are based on, to get as many details as we can. Second, whatever data we come up with needs to be put in tzdata form, with commentary citing the sources. You can look at the existing 'northamerica' and 'backzone' files for examples, and read the tzfile man page (and the file 'Theory', which explains naming and in particular why we shouldn't use the name 'America/North_Carolina') for details. The result should be a patch to the file 'backone' in Git form. If that's all done and the patch goes in, you should be able to run 'make posix_packrat', and use the result in your programs.

1 0

Possible DST Discrepancies for Manitoba, Canada
by Rena B Dec. 7, 2015

Dec. 7, 2015

Across the board, I've come across a possible discrepancy that I can't seem to let go off. The years 1957 - 1963 in the data base for Manitoba. Winnipeg and Selkirk both switch for those years appropriately, but none of the other Manitoba towns I've tried have. My birth date is June 1957 in one of the town and I cannot find out if DST was province wide for that year. I believe there were 2 years in this time frame that Winnipeg did not subscribe to DST (1960-61). Would very much appreciate if you have the resources to look into this? If the rest of the towns in Manitoba followed Winnipeg/Selkirk, then there is a large error margin happening. Regards, Rena Bergman

3 2

Question about historical TZData for North Carolina
by Clifford Ribaudo Dec. 7, 2015

Dec. 7, 2015

Hi, I’m working on some astronomical/astrological software and looking for open source Historical Time Zone data. Obviously I’m looking at tzdata but find that while some local peculiarities are covered such as Indiana, but places like North Carolina are not? Specifically, there does not appear to be a way to do a tzdump for America/North_Carolina to get the adoption of DST in 1966? Am I missing something here? North Carolina appears to be grouped under America/New_York, however New York DST adoption was very different from some of the other more “stubborn” states in the Eastern Zone. I would like to propose that Zone Names be added for each state and which at a minimum simply model the adoption of DST in 1966. This is helpful to applications like mine that look up a zone name by lat/lng and then try to get a Time Zone for a date. Thanks, Cliff Ribaudo cr(a)iphemeris.com

3 3

south korea will use DST in 2016
by Sebastien WILLEMIJNS Dec. 6, 2015

Dec. 6, 2015

hello, dunno if it was displayed here http://french.yonhapnews.co.kr/news/2015/12/06/0200000000AFR201512060003008…

4 3

efele.net/tz maps updated
by Eric Muller Nov. 29, 2015

Nov. 29, 2015

I have updated the efele.net/tz maps (http://efele.net/maps/tz/) to be in sync with TZ 2015g. The new zones: Pacific/Bougainville Asia/Chita Asia/Srednekolymsk America/Fort_Nelson Antarctica/Troll Eric.

7 8

Machine-readable time zones diff/changelog?
by Максим Кочкин Nov. 27, 2015

Nov. 27, 2015

Hi. Recently I've run into an issue with time zones splitting, it's described in this my SO question — http://stackoverflow.com/questions/33943855/how-to-handle-new-time-zone/339… — and covered by a brilliant answer by Matt Johnson ( http://stackoverflow.com/a/33946308/487923) Matt also mentioned that there was a discussion about some machine-readable tz diff that can help developers to handle that changes like split automatically. Did you try to create a standardized diff/changelog? If not — why not? Or is it only me who needs it, and it can be handled in some other easier way?

2 1

TZ Updater
by Victor Uribe Nov. 26, 2015

Nov. 26, 2015

To whom it may concern, I am in need of acquiring the tz updater version JDK-8054458 found at http://bugs.java.com/view_bug.do?bug_id=8054458 since the Java time is no longer synchronized correctly. Where can I find this file to use on an XP machine running Java 6 update 30. Thank you. Regards, Victor Uribe Application Engineer Modular Mining Systems, Inc. 3289 E. Hemisphere Loop Tucson, Arizona 85706- 5028 USA +1 (520) 344-6376 (work) +1 (602) 762-0213 (cell) vuribe(a)mmsi.com<mailto:vuribe@mmsi.com> www.mmsi.com<http://www.mmsi.com> MODULAR - Mine Smarter™ _________________________________ The information contained in this email, including all attachments, is intended solely for the use of the individual or entity to whom it is addressed and may contain information that is privileged, proprietary and/or confidential. If the reader of this message is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any perusal, use, dissemination, or disclosure is strictly prohibited. Confidentiality, privilege, or copyright is not waived or lost because you have received this message in error. If you have received this message in error, please notify us immediately by reply email or email postmaster(a)mmsi.com and destroy the original message and any copies. Modular®, IntelliMine®, DISPATCH®, ProVision®, MineCare®, MasterLink®, PowerView ™, and ModularReady® are trademarks and/or registered trademarks and the sole and exclusive property of Modular Mining Systems, Inc.

2 1

More Russian Changes
by Matt Johnson Nov. 25, 2015

Nov. 25, 2015

FYI - Two draft bills are posted on the Russian government's web site: http://government.ru/activities/20702/ http://government.ru/activities/20703/ If approved, the effect would be to move the Astrakhan region from UTC+3 to UTC+4, and to move the Trans-Baikal region from UTC+8 to UTC+9. Neither bill mentions an effective date. It's not clear whether the Trans-Baikal region refers to the entire area of Zabaykalsky Krai or some subset. Zabaykalsk Krai is currently managed by the Asia/Chita time zone, which I assume would remain intact and just get a new row in its zone entry. Also, assuming by Astrakhan region they mean the Astrakhan Oblast, then I think this change would require a new time zone. I suggest Europe/Astrakan for the city of the same name in this region. This is split from the Europe/Volograd time zone. -Matt

1 2

Coordinated Universal Time (UTC) to retain “leap second”
by Brian Inglis Nov. 20, 2015

Nov. 20, 2015

http://www.itu.int/net/pressoffice/press_releases/2015/53.aspx -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

10 15

Coordinated Universal Time (UTC) to retain “leap second”
by Brian Inglis Nov. 19, 2015

Nov. 19, 2015

http://www.itu.int/net/pressoffice/press_releases/2015/53.aspx -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

1 0

zoneinfo vs zoneinfo-leaps
by Ken Murchison Nov. 17, 2015

Nov. 17, 2015

Maybe this is a FAQ but I haven't found the answer. Having studied up the tzfile(5) format and written some code to produce these files, I'm wondering why the files in zoneinfo-leaps include the leap records AND adjust the transition times by the appropriate number of leap seconds. This seems redundant to me. If the file includes the leap second records, why not let the consumer adjust the transitions? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

7 11

Note of thanks - Australian Tz Acronyms [SEC=UNCLASSIFIED]
by Peter Stagg Nov. 17, 2015

Nov. 17, 2015

This week we (The Australian Bureau of Meteorology) updated the TZ database on our web systems to the latest version and we are finally able to display Australian time zone acronyms properly via scripts using the TZ database - AEST, AEDT etc. Thanks for the inclusion of these in the TZ database. Regards, Peter Stagg | Web Systems Technology Officer [bureau_logo] Web Systems, Platform Services, Information Technology Services, Information Systems & Services Division, Bureau of Meteorology GPO Box 1289 Melbourne VIC 3001 Level 6, 700 Collins Street, Docklands VIC 3008 Tel: +61 3 9669 4232 | p.stagg(a)bom.gov.au www.bom.gov.au<http://www.bom.gov.au/>

1 0

[PROPOSED PATCH] Improve guesses for post-2037 Iran
by Paul Eggert Nov. 14, 2015

Nov. 14, 2015

* NEWS: Document this. * asia (Iran): Predict 2038 and later DST to be March 21 thru Sept. 21. This is not correct, but it's better than predicting no DST. --- NEWS | 6 ++++++ asia | 11 +++++++++-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index b4e1483..121e0e4 100644 --- a/NEWS +++ b/NEWS @@ -11,6 +11,12 @@ Unreleased, experimental changes America/Metlakatla switched from PST all year to AKST/AKDT on 2015-11-01 at 02:00. (Thanks to Steffen Thorsen.) + Changes affecting future time stamps + + Asia/Tehran now has DST predictions for the year 2038 and later, + to be March 21 00:00 to September 21 00:00. This is likely better + than predicting no DST, albeit off by a day every now and then. + Changes affecting documentation tz-link.htm mentions the BDE library (thanks to Andrew Paprocki). diff --git a/asia b/asia index 5467024..f170244 100644 --- a/asia +++ b/asia @@ -1084,8 +1084,15 @@ Rule Iran 2032 2033 - Mar 21 0:00 1:00 D Rule Iran 2032 2033 - Sep 21 0:00 0 S Rule Iran 2034 2035 - Mar 22 0:00 1:00 D Rule Iran 2034 2035 - Sep 22 0:00 0 S -Rule Iran 2036 2037 - Mar 21 0:00 1:00 D -Rule Iran 2036 2037 - Sep 21 0:00 0 S +# +# The following rules are approximations starting in the year 2038. +# These are the best post-2037 approximations available, given the +# restrictions of a single rule using a Gregorian-based data format. +# At some point this table will need to be extended, though quite +# possibly Iran will change the rules first. +Rule Iran 2036 max - Mar 21 0:00 1:00 D +Rule Iran 2036 max - Sep 21 0:00 0 S + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tehran 3:25:44 - LMT 1916 3:25:44 - TMT 1946 # Tehran Mean Time -- 2.5.0

1 0

America/Metlakatla now follows Alaska
by Steffen Thorsen Nov. 13, 2015

Nov. 13, 2015

It seems Metlakatla did go off PST on Sunday, November 1, changing their time to AKST and are going to follow Alaska's DST, switching between AKST and AKDT from now on. Based on: http://www.krbd.org/2015/10/30/annette-island-times-they-are-a-changing/ Best regards, Steffen Thorsen - timeanddate.com

12 18

A discussion on POSIX on new timezone related C APIs
by Random832 Nov. 13, 2015

Nov. 13, 2015

http://austingroupbugs.net/view.php?id=1005 The proposals seem to be: 1. Something involving integrating timezone information into locale_t 2. Something along the lines of NetBSD's _z/_rz functions The fact that no-one seems to have a reference C implementation of localizing time zone names/abbreviations also came up. I don't know how open they are to outsiders sticking their noses into the process though, just thought some people here might be interested. Also proposed is the addition of "tm_nsec" to struct tm, and the new APIs in one of the proposals use a struct timespec rather than time_t.

4 4

Re: [tz] efele.net/tz maps updated
by Steve Jones Nov. 11, 2015

Nov. 11, 2015

At 08:13 PM 11/10/2015, Chris Walton wrote: >There is one (and only one) community in the >western half of the PRRD;Â it is the isolated >community of Fort Ware (also known as >Kwadacha).Â It has a population of about 270. There is another - Tsay Keh Deme, about 86km to the south (56.892014, -124.963373). Population 245. I imagine it also observes Vancouver time. I have tried to reach out to the RCMP detachment office there via the "contact us" thingy on the RCMP website, but have not received any response. I didn't feel like making an international call. Their detachment webpage is: www.rcmp-grc.gc.ca/detach/en/d/212. If it's a free call for you, it may be worth giving them a ring. There area of coverage is basically the whole western part of the PRRD. I imagine they could speak with some authority about whatever time zone observances may be practiced throughout the area. But it has to be Pacific time - nothing else makes sense regardless of the opinion of the GIS folks at the PRRD. Their primary economic ties will be outside the PRRD to their south and west. Regards, Steve Jones Emacs! 14h pg

2 1

Re: [tz] efele.net/tz maps updated
by Steve Jones Nov. 11, 2015

Nov. 11, 2015

Sorry, typo, it's Dene, not Deme. Tsay Keh Dene. >There is another - Tsay Keh Deme, about 86km to the south \ Regards, Steve Jones Emacs!

1 0

Re: [tz] America/Santa_Isabel
by Steve Jones Nov. 10, 2015

Nov. 10, 2015

At 01:19 PM 11/9/2015, Matt Johnson (PNP) wrote: >Our research concluded that there is no known location in the state >of Baja California that observes Mexican DST rules. All are on US >DST rules. The 20km boundary mentioned in the law applies in the >other Mexican states, but not in Baja California due to the >exclusions mentioned in the same law. One more data point in support of your conclusion: I reached out to a contact on Cedros Island, which nearly touches the southern border of Baja. He indicates that clocks on the island adjusted on November 1. Regards, Steve Jones Emacs!

1 0

Re: [tz] America/Santa_Isabel
by Matt Johnson (PNP) Nov. 9, 2015

Nov. 9, 2015

WRT my previous comment: "I've got a parallel discussion going within Microsoft about this zone, and will share the findings of our research. " Our research concluded that there is no known location in the state of Baja California that observes Mexican DST rules. All are on US DST rules. The 20km boundary mentioned in the law applies in the other Mexican states, but not in Baja California due to the exclusions mentioned in the same law. This agrees with ADO’s observations about San Quintin. Also, the Wikipedia information about San Quintin becoming its own municipality is outdated. The decision was overturned by the Mexican supreme court due to jurisdictional issues. See: http://www2.scjn.gob.mx/juridica/engroses/cerrados/Publico/13000980.009-268… Thanks, Matt Johnson Microsoft ________________________________ Date: Sun, 1 Nov 2015 20:32:17 -0500 From: arthurdavidolson(a)gmail.com<mailto:arthurdavidolson@gmail.com> To: tz(a)iana.org<mailto:tz@iana.org> Subject: Re: [tz] America/Santa_Isabel And in today's final listen, XEQIN announced "cinco de la tarde con veinticuatro minutos" (literally "5 of the afternoon with 24 minutes") at about 8:24 PM USEST--the same as 5:24 PM USPST. At least this year, San Quintín seems to have followed has followed US rules. So much for that bookmark. @dashdashado On Sat, Oct 31, 2015 at 10:12 PM, Arthur David Olson <arthurdavidolson(a)gmail.com<mailto:arthurdavidolson@gmail.com>> wrote: This evening's next-to-last listen to XEQIN included advice to listeners to "atrarse una hora de su reloj" ("delay your clock by an hour") tonight before going to bed. The end-of-broadcast-day national anthem, due at 7:00 p. m. local time, came shortly after 10:00 p.m. USEDT, consistent with San Quintín still being on daylight saving time. The last listen should be tomorrow or Monday evening. @dashdashado On Tue, Oct 27, 2015 at 3:44 PM, Matt Johnson <mj1856(a)hotmail.com<mailto:mj1856@hotmail.com>> wrote: Acknowledged. Thanks for the clarification. -Matt ________________________________ From: Paul Eggert<mailto:eggert@cs.ucla.edu> Sent: ‎10/‎27/‎2015 10:31 AM To: Matt Johnson<mailto:mj1856@hotmail.com> Cc: Time Zone Mailing List<mailto:tz@iana.org> Subject: Re: [tz] America/Santa_Isabel Matt Johnson wrote: > there is a corresponding entry in Windows, "Pacific Standard Time (Mexico) |(UTC-08:00) Baja California" I'm afraid this will have to be adjusted on the Microsoft end. There needs to be a procedure for removing time zones that turn out to be mistakes. America/Santa_Isabel is a mistake, and I suppose we can view this as an opportunity for ironing out any procedural glitches while removing it. We do have a backward compatibility link on the tzdata side; perhaps that will help for the Microsoft side. > Also, there's a chance that San Quintin could indeed start using Mexican DST rules in 2017, We can create a zone America/San_Quintin if that happens.

1 0

No surprises in Trans-Pacific Partnership
by Arthur David Olson Nov. 5, 2015

Nov. 5, 2015

At least if the Washington Post's search... https://www.washingtonpost.com/news/the-fix/wp/2015/11/05/we-made-president… ...is to be believed, the Trans-Pacific Partnership mega-treaty has nothing to say about any "time zone"--phew. @dashdashado

1 0

Utility to dump raw values from binary zoneinfo files
by Andrew Paprocki Nov. 4, 2015

Nov. 4, 2015

I just released a little public domain utility I wrote to dump the raw values from zic-compiled binary files. This mainly aids anyone writing a zoneinfo reader who wants to easily view the binary structure and/or anyone creating contextual diffs from binary files. I'm posting it here in case anyone else finds it useful or wants to include it in tzcode. -Andrew https://github.com/apaprocki/zid Example output: $ ./zid /usr/share/zoneinfo/Etc/GMT 32: tzh: magic 'TZif' 32: tzh: version 2 32: tzh: ttisgmtcnt 1 32: tzh: ttisstdcnt 1 32: tzh: leapcnt 0 32: tzh: timecnt 0 32: tzh: typecnt 1 32: tzh: charcnt 4 32: gmtoff 0 isdst 0 abbrind 0 (GMT) 32: ttisstdcnt[0]: 0 32: ttisgmtcnt[0]: 0 64: tzh: magic 'TZif' 64: tzh: version 2 64: tzh: ttisgmtcnt 1 64: tzh: ttisstdcnt 1 64: tzh: leapcnt 0 64: tzh: timecnt 0 64: tzh: typecnt 1 64: tzh: charcnt 4 64: offset 0 isdst 0 abbrind 0 (GMT) 64: ttisstdcnt[0]: 0 64: ttisgmtcnt[0]: 0 TZ: 'GMT0'

1 0

Leap second coverage in mainstream media
by Arthur David Olson Nov. 4, 2015

Nov. 4, 2015

>From The Economist: "Why time may be running out for the leap second" http://www.economist.com/blogs/economist-explains/2015/11/economist-explain… @dashdashado

2 1

Fallback rules?
by Alfie John Nov. 4, 2015

Nov. 4, 2015

Hi TZers, Sorry if this has been asked before, but I couldn't find any documentation on the rules of what should happen for the following circumstances. Here's the definition for Australia/Brisbane: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule AQ 1971 only - Oct lastSun 2:00s 1:00 D Rule AQ 1972 only - Feb lastSun 2:00s 0 S Rule AQ 1989 1991 - Oct lastSun 2:00s 1:00 D Rule AQ 1990 1992 - Mar Sun>=1 2:00s 0 S Rule Holiday 1992 1993 - Oct lastSun 2:00s 1:00 D Rule Holiday 1993 1994 - Mar Sun>=1 2:00s 0 S Zone Australia/Brisbane 10:12:08 - LMT 1895 10:00 Aus AE%sT 1971 10:00 AQ AE%sT As the zone ends with AQ, and AQ does not have a "max" ending date, what should Australia/Brisbane fall back to after 1992? I thought maybe in this instance perhaps "Aus" as it's the one above it, but "Aus" seem to oddly be specific to both World Wars. I also don't think that it should then fall back to a GMTOFF = "10:12:08". That sounds awkward. Thanks, Alfie -- Alfie John alfie(a)fastmail.com

5 9