Victor Uribe | 24 Nov 21:17 2015

[tz] TZ Updater

To whom it may concern,


I am in need of acquiring the tz updater version JDK-8054458 found at 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.




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 <at>


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 <at> 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.
Matt Johnson | 24 Nov 09:00 2015

[tz] More Russian Changes

FYI - Two draft bills are posted on the Russian government's web site:

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.

Brian Inglis | 19 Nov 18:30 2015

[tz] Coordinated Universal Time (UTC) to retain “leap second”

Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

Brian Inglis | 20 Nov 02:57 2015

[tz] Coordinated Universal Time (UTC) to retain “leap second”

Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

Peter Stagg | 17 Nov 05:56 2015

[tz] Note of thanks - Australian Tz Acronyms [SEC=UNCLASSIFIED]

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.




Peter Stagg | Web Systems Technology Officer

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 <at>


Ken Murchison | 16 Nov 21:48 2015

[tz] zoneinfo vs zoneinfo-leaps

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

Paul Eggert | 14 Nov 07:07 2015

[tz] [PROPOSED PATCH] Improve guesses for post-2037 Iran

* 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
 <at>  <at>  -11,6 +11,12  <at>  <at>  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
 <at>  <at>  -1084,8 +1084,15  <at>  <at>  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	Asia/Tehran	3:25:44	-	LMT	1916
 			3:25:44	-	TMT	1946     # Tehran Mean Time


Random832 | 12 Nov 20:33 2015

[tz] A discussion on POSIX on new timezone related C APIs

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.

Steve Jones | 11 Nov 04:48 2015

Re: [tz] maps updated

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:  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.


Steve Jones

14h pg
Steve Jones | 10 Nov 08:28 2015

Re: [tz] America/Santa_Isabel

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.


Steve Jones

Matt Johnson (PNP | 9 Nov 20:19 2015

Re: [tz] America/Santa_Isabel

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:





Matt Johnson

Date: Sun, 1 Nov 2015 20:32:17 -0500
arthurdavidolson <at>
tz <at>
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.


    <at> dashdashado


On Sat, Oct 31, 2015 at 10:12 PM, Arthur David Olson <arthurdavidolson <at>> 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.

    <at> dashdashado


On Tue, Oct 27, 2015 at 3:44 PM, Matt Johnson <mj1856 <at>> wrote:

Acknowledged.  Thanks for the clarification.


From: Paul Eggert
Sent: ‎10/‎27/‎2015 10:31 AM
To: Matt Johnson
Cc: Time Zone Mailing List
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.