September 2016 - tz - lists.iana.org

proposed time zone package changes (Samoa, Factory, et al.)
by Arthur David Olson Aug. 28, 2019

Aug. 28, 2019

Below find proposed time zone package changes; the executive summary: * Makefile Change LOCALTIME default from "Factory" to "GMT"; do not compile "factory" file (but keep it in the distribution). * Theory Remove reference to "Factory" zone. * australasia Change end of DST in Samoa in 2011 from 2011-04-03 0:00 to 2011-04-03 1:00 (thanks to Raymond Hughes for a reference). * localtime.c Initialize ttinfo structures filled by tzparse (thanks to Ravindra for reporting a valgrind warning). * zic.c Fix generation of POSIX strings for zones with rules using "weekday<=n" forms of dates (thanks to Lei Liu for finding the problem). Also, limit output for non-POSIX-specificable zones defined to follow the same rules every year. (Note that no zones of either of the above types appear in the distribution; these changes cater to add-on zones). If no problems are found, 2010n will appear on 2010-10-25. --ado diff -r -c old/Makefile new/Makefile *** old/Makefile Mon Sep 27 09:24:25 2010 --- new/Makefile Tue Oct 12 12:36:50 2010 *************** *** 1,5 **** # <pre> ! # @(#)Makefile 8.8 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)Makefile 8.9 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 12,18 **** # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= Factory # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, --- 12,18 ---- # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= GMT # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, *************** *** 262,269 **** DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera factory backward ! NDATA= systemv SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab --- 262,269 ---- DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera backward ! NDATA= systemv factory SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab diff -r -c old/Theory new/Theory *** old/Theory Mon Sep 27 09:24:25 2010 --- new/Theory Tue Oct 12 12:36:50 2010 *************** *** 1,4 **** ! @(#)Theory 8.4 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. --- 1,4 ---- ! @(#)Theory 8.5 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. *************** *** 287,294 **** See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', `EET' (see the file `europe'), ! and `Factory' (see the file `factory'). ----- Time zone abbreviations ----- --- 287,293 ---- See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', and `EET' (see the file `europe'). ----- Time zone abbreviations ----- diff -r -c old/australasia new/australasia *** old/australasia Mon Sep 27 09:24:27 2010 --- new/australasia Tue Oct 12 13:14:56 2010 *************** *** 1,5 **** # <pre> ! # @(#)australasia 8.18 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)australasia 8.19 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 487,497 **** # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </a> Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time -11:00 - WST 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 -11:00 - WST # Solomon Is --- 487,507 ---- # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </a> + # From Raymond Hughes (2010-10-07): + # Please see + # <a href="http://www.mcil.gov.ws"> + # http://www.mcil.gov.ws + # </a>, + # the Ministry of Commerce, Industry and Labour (sideframe) "Last Sunday + # September 2010 (26/09/10) - adjust clocks forward from 12:00 midnight + # to 01:00am and First Sunday April 2011 (03/04/11) - adjust clocks + # backwards from 1:00am to 12:00am" + Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time -11:00 - WST 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 1:00 -11:00 - WST # Solomon Is diff -r -c old/localtime.c new/localtime.c *** old/localtime.c Mon Sep 27 09:24:26 2010 --- new/localtime.c Tue Oct 12 12:36:51 2010 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.14"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.15"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 914,919 **** --- 914,920 ---- register unsigned char * typep; register char * cp; register int load_result; + static struct ttinfo zttinfo; INITIALIZE(dstname); stdname = name; *************** *** 986,991 **** --- 987,993 ---- /* ** Two transitions per year, from EPOCH_YEAR forward. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -dstoffset; sp->ttis[0].tt_isdst = 1; sp->ttis[0].tt_abbrind = stdlen + 1; *************** *** 1099,1106 **** } /* ** Finally, fill in ttis. - ** ttisstd and ttisgmt need not be handled. */ sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; --- 1101,1108 ---- } /* ** Finally, fill in ttis. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; *************** *** 1113,1118 **** --- 1115,1121 ---- dstlen = 0; sp->typecnt = 1; /* only standard time */ sp->timecnt = 0; + sp->ttis[0] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = 0; sp->ttis[0].tt_abbrind = 0; diff -r -c old/zic.c new/zic.c *** old/zic.c Mon Sep 27 09:24:26 2010 --- new/zic.c Tue Oct 12 13:37:29 2010 *************** *** 3,9 **** ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.22"; #include "private.h" #include "locale.h" --- 3,9 ---- ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.24"; #include "private.h" #include "locale.h" *************** *** 1881,1896 **** register int week; if (rp->r_dycode == DC_DOWGEQ) { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if ((week - 1) * DAYSPERWEEK + 1 != rp->r_dayofmonth) return -1; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if (week * DAYSPERWEEK - 1 != rp->r_dayofmonth) return -1; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", --- 1881,1896 ---- register int week; if (rp->r_dycode == DC_DOWGEQ) { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 1) return -1; + week = 1 + rp->r_dayofmonth / DAYSPERWEEK; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 0) return -1; + week = rp->r_dayofmonth / DAYSPERWEEK; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", *************** *** 2018,2023 **** --- 2018,2024 ---- register char * envvar; register int max_abbr_len; register int max_envvar_len; + register int prodstic; /* all rules are min to max */ max_abbr_len = 2 + max_format_len + max_abbrvar_len; max_envvar_len = 2 * max_abbr_len + 5 * 9; *************** *** 2032,2037 **** --- 2033,2039 ---- timecnt = 0; typecnt = 0; charcnt = 0; + prodstic = zonecount == 1; /* ** Thanks to Earl Chew ** for noting the need to unconditionally initialize startttisstd. *************** *** 2053,2058 **** --- 2055,2062 ---- updateminmax(rp->r_loyear); if (rp->r_hiwasnum) updateminmax(rp->r_hiyear); + if (rp->r_lowasnum || rp->r_hiwasnum) + prodstic = FALSE; } } /* *************** *** 2075,2080 **** --- 2079,2094 ---- if (max_year <= INT_MAX - YEARSPERREPEAT) max_year += YEARSPERREPEAT; else max_year = INT_MAX; + /* + ** Regardless of any of the above, + ** for a "proDSTic" zone which specifies that its rules + ** always have and always will be in effect, + ** we only need one cycle to define the zone. + */ + if (prodstic) { + min_year = 1900; + max_year = min_year + YEARSPERREPEAT; + } } /* ** For the benefit of older systems,

5 6

Syntax highlighting for Sublime Text
by Gilmore Davidson Aug. 16, 2017

Aug. 16, 2017

Hi, I’ve created some tzdata syntax highlighting rules for the Sublime Text editor: https://packagecontrol.io/packages/zoneinfo <https://packagecontrol.io/packages/zoneinfo> I have no idea if anyone other than me uses that particular text editor for looking at tzdata files. But I thought I’d mention it just in case it’s useful to someone. Cheers, Gil

3 3

Re: [tz] Version in zoneinfo files?
by Guy Harris Feb. 10, 2017

Feb. 10, 2017

On Oct 25, 2015, at 10:55 AM, Paul G <paul(a)ganssle.io> wrote: > I'm not suggesting that it be impossible to create a weird result when asking for the version, just that there's a standard place for the version to go, and preferably the standard default gives you something that you expected. I.e., something that works most of the time is sufficient? So what exactly is the intended use of this version field? > As it is now, you're virtually guaranteed to have a lot of incompatibility because there's nothing you can point to that says, "This is the canonical way to store version information about zoneinfo files", and no standard has emerged on how to do this as is. > > On 10/25/2015 01:51 PM, Guy Harris wrote: >> >> On Oct 25, 2015, at 10:37 AM, Paul G <paul(a)ganssle.io> wrote: >> >>> On 10/25/2015 01:35 PM, Guy Harris wrote: >>> >>>> So where would zic get the version information to put into the binary files? >>> >>> My understanding is that it's the VERSION= line of the Makefile in the tzdata tarballs. >> >> I.e., you're proposing that the value of the VERSION value in the Makefile be passed as an argument to zic, and zic would put the value of that argument into a field in the files? >> >> So, if the goal is to provide a "reliable way to get the version information in a cross-platform way", what would ensure that this field be set properly, for some value of "properly", everywhere that binary tzdata files are generated? >> >> I.e., what is to guarantee that >> >> 1) nobody downstream change VERSION if they aren't changing the zic files from what's distributed >> >> and >> >> 2) people change it "properly" if the files don't correspond to a particular version of files that were distributed (e.g., if some downstream supplier takes 2015q and adds some changes mentioned on the list to it before 2015r comes out with those changes plus other changes, they should call the resulting files something other than "2015q" or "2015r")? >> >

20 55

Proposal: validation text file with releases
by Jon Skeet Dec. 19, 2016

Dec. 19, 2016

Background: I'm the primary developer for Noda Time <http://nodatime.org> which consumes the tz data. I'm currently refactoring the code to do this... and I've come across some code (originally ported from Joda Time) which I now understand in terms of what it's doing, but not exactly why. For a little while now, the Noda Time source repo has included a text dump file <https://github.com/nodatime/nodatime/blob/master/src/NodaTime.Test/TestData…>, containing a text dump of every transition (up to 2100, at the moment) for every time zone. It looks like this, picking just one example: Zone: Africa/Maseru LMT: [StartOfTime, 1892-02-07T22:08:00Z) +01:52 (+00) SAST: [1892-02-07T22:08:00Z, 1903-02-28T22:30:00Z) +01:30 (+00) SAST: [1903-02-28T22:30:00Z, 1942-09-20T00:00:00Z) +02 (+00) SAST: [1942-09-20T00:00:00Z, 1943-03-20T23:00:00Z) +03 (+01) SAST: [1943-03-20T23:00:00Z, 1943-09-19T00:00:00Z) +02 (+00) SAST: [1943-09-19T00:00:00Z, 1944-03-18T23:00:00Z) +03 (+01) SAST: [1944-03-18T23:00:00Z, EndOfTime) +02 (+00) I use this file for confidence when refactoring my time zone handling code - if the new code comes up with the same set of transitions as the old code, it's probably okay. (This is just one line of defence, of course - there are unit tests, though not as many as I'd like.) It strikes me that having a similar file (I'm not wedded to the format, but it should have all the same information, one way or another) released alongside the main data files would be really handy for *all* implementors - it would be a good way of validating consistency across multiple platforms, with the release data being canonical. For any platforms which didn't want to actually consume the rules as rules, but just wanted a list of transitions, it could even effectively replace their use of the data. One other benefit: diffing the dump between two releases would make it clear what had changed in *effect*, rather than just in terms of rules. One sticking point is size. The current file for Noda Time is about 4MB, although it zips down to about 300K. Some thoughts around this: - We wouldn't need to distribute it in the same file as the data - just as we have data and code file, there could be a "textdump" file or whatever we'd want to call it. These could be retroactively generated for previous releases, too. - As you can see, there's redundancy in the format above, in that it's a list of "zone intervals" (as I call them in Noda Time) rather than a list of transitions - the end of each interval is always the start of the next interval. - For zones which settle into an infinite daylight saving pattern, I currently generate from the start of time to 2100 (and then a single zone interval for the end of time as Noda Time understands it; we'd need to work out what form that would take, if any). If we decided that "year of release + 30 years" was enough, that would cut down the size considerably. Any thoughts? If the feeling is broadly positive, the next step would be to nail down the text format, then find a willing victim/volunteer to write the C code. (You really don't want me writing C...) Jon

18 92

tzdata2016g missing version information
by Howard Hinnant Nov. 11, 2016

Nov. 11, 2016

As is known, the version number no longer appears in the Makefile. The release notes in NEWS say: > To support the more-accurate version number, its > specification has moved from a line in the Makefile to a new > source file 'version’. The version file does not appear in the uncompressed tzdata2016g database. This is hurting my ability to report the version of the database to my clients. Can we please put a version file in the database? Howard

18 49

[PROPOSED PATCH] Cyprus is splitting into two time zones
by Paul Eggert Nov. 2, 2016

Nov. 2, 2016

Add a zone Asia/North_Nicosia for North Cyprus. * NEWS: Document this. * asia, zone.tab, zone1970.tab (Asia/North_Nicosia): New zone. --- NEWS | 5 +++-- asia | 11 ++++++++++- zone.tab | 3 ++- zone1970.tab | 3 ++- 4 files changed, 17 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index a4af3b2..64233bf 100644 --- a/NEWS +++ b/NEWS @@ -5,8 +5,9 @@ Unreleased, experimental changes Changes to future time stamps Turkey switched from EET/EEST (+02/+03) to permanent +03, - effective 2016-09-07. (Thanks to Burak AYDIN.) Use "+03" rather - than an invented abbreviation for the new time. + effective 2016-09-07. (Thanks to Burak AYDIN.) Northern Cyprus + followed suit the next day, which creates a zone Asia/North_Nicosia. + Use "+03" rather than an invented abbreviation for the new time. New leap second 2016-12-31 23:59:60 UTC as per IERS Bulletin C 52. (Thanks to Tim Parenti.) diff --git a/asia b/asia index e285326..4462cd4 100644 --- a/asia +++ b/asia @@ -773,6 +773,12 @@ Zone Asia/Macau 7:34:20 - LMT 1912 Jan 1 # Cyprus # # Milne says the Eastern Telegraph Company used 2:14:00. Stick with LMT. +# IATA SSIM (1998-09) has Cyprus using EU rules for the first time. +# +# From Paul Eggert (2016-09-09): +# Yesterday's Cyprus Mail reports that Northern Cyprus followed Turkey's +# lead and switched from +02/+03 to +03 year-round. +# http://cyprus-mail.com/2016/09/08/two-time-zones-cyprus-turkey-will-not-tur… # # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Cyprus 1975 only - Apr 13 0:00 1:00 S @@ -788,7 +794,10 @@ Rule Cyprus 1981 1998 - Mar lastSun 0:00 1:00 S Zone Asia/Nicosia 2:13:28 - LMT 1921 Nov 14 2:00 Cyprus EE%sT 1998 Sep 2:00 EUAsia EE%sT -# IATA SSIM (1998-09) has Cyprus using EU rules for the first time. +Zone Asia/North_Nicosia 2:13:27 - LMT 1921 Nov 14 + 2:00 Cyprus EE%sT 1998 Sep + 2:00 EUAsia EE%sT 2016 Sep 8 + 3:00 - +03 # Classically, Cyprus belongs to Asia; e.g. see Herodotus, Histories, I.72. # However, for various reasons many users expect to find it under Europe. diff --git a/zone.tab b/zone.tab index bf1bb71..15989f4 100644 --- a/zone.tab +++ b/zone.tab @@ -152,7 +152,8 @@ CU +2308-08222 America/Havana CV +1455-02331 Atlantic/Cape_Verde CW +1211-06900 America/Curacao CX -1025+10543 Indian/Christmas -CY +3510+03322 Asia/Nicosia +CY +3510+03322 Asia/Nicosia Cyprus (most areas) +CY +3511+03322 Asia/North_Nicosia North Cyprus CZ +5005+01426 Europe/Prague DE +5230+01322 Europe/Berlin Germany (most areas) DE +4742+00841 Europe/Busingen Busingen diff --git a/zone1970.tab b/zone1970.tab index 49f0b0b..efe27b1 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -144,7 +144,8 @@ CU +2308-08222 America/Havana CV +1455-02331 Atlantic/Cape_Verde CW,AW,BQ,SX +1211-06900 America/Curacao CX -1025+10543 Indian/Christmas -CY +3510+03322 Asia/Nicosia +CY +3510+03322 Asia/Nicosia Cyprus (most areas) +CY +3511+03322 Asia/North_Nicosia North Cyprus CZ,SK +5005+01426 Europe/Prague DE +5230+01322 Europe/Berlin Germany (most areas) DK +5540+01235 Europe/Copenhagen -- 2.7.4

11 23

Geolocation extension to tzdist
by Ken Murchison Oct. 19, 2016

Oct. 19, 2016

All, (sending to tz(a)iana.org since tzdist(a)ietf.org appears to be dead) I was bored today (actually avoiding "real" work) and was playing around with the ESRI shapefile for timezones <http://efele.net/maps/tz/world/> I hacked up a quick extension to my tzdist implementation using the tz_world shapefile and basic ray tracing to be able to query a time zone by geo coordinates, similar to what Google offers in their Time Zone API. Note that I have yet to spend any time writing code to account for "holes" in time zones like the Navajo Reservation in Arizona. I modeled the extension after the "find" action in RFC 7808 but with lat/long query params rather than a glob pattern. A request and response for the timezone in which my home is located looks something like this: GET /tzdist/zones?latitude=43.070833&longitude=-78.831667 HTTP/1.1 { "synctoken": "890939292-1466089793", "timezones": [ { "tzid": "America/New_York", "etag": "6602582-1466089793", "last-modified": "2016-06-16T15:09:53Z", "publisher": "IANA Time Zone Database", "version": "2016e", "aliases": [ "US/Eastern" ] } ] } The definition of the extension looks like this in the capabilities response: { "name": "geolocate", "uri-template": "/zones{?latitude,longitude}", "parameters": [ { "name": "latitude", "required": true }, { "name": "longitude", "required": true } ] } Currently my code only accepts coordinates in decimal degrees, but I think it should probably support ISO 6709 formats. Is this something that folks would like to see documented as a formal extension to tzdist, either as specified above or with some modification? If so, I'd be willing to write it up as a draft and then move it through IETF in whatever fashion the ADs recommend. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

4 5

Are tzdata2016g & tzdata-latest missing the VERSION file?
by Barry Allard Sept. 30, 2016

Sept. 30, 2016

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, Thanks to all the folks whom have maintained and contributed to this vital database over the for years. Has the format changed somehow? If this and future database files were to break backwards-compatibility arbitrarily, it would be an unwelcome, breaking change for potentially tens- to hundreds-of-thousands of deployed endpoints and would an expensive burden and require lots of system software providers to repackage and push new software to untold millions to billions of endpoints, some of which are for-all-practical-purposes immutable (such as embedded systems / SCADA). In short: it would make a lot of people mad because it would be very expensive and time-consuming to change. For example, here's just one error from a wide-deployed utility (TZUpdater 2.1) which worked using tzdata2016f, but not with tzdata-latest nor tzdata2016g: $ java -jar tzupdater.jar -l https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz Using https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz as source for tzdata bundle. Source directory does not contain file: VERSION $ $ java -jar tzupdater.jar -l https://www.iana.org/time-zones/repository/releases/tzdata2016f.tar.gz Using https://www.iana.org/time-zones/repository/releases/tzdata2016f.tar.gz as source for tzdata bundle. JRE has the same version as the tzupdater provided one (tzdata2016f). $ If I might humbly suggest continuing using what was a de-facto standard for stability and least-surprise, where at all possible. Thanks, Barry Allard PS: I saw a related past discussion but can't respond to it right now. -----BEGIN PGP SIGNATURE----- Version: Mailvelope v1.5.2 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJX7i2oCRAUysGWoSICbAAAR4QP/1MoTcbGQC7IfGNOZ1z3 nwl4FQIqJc7sECdA57AgGfjMQvweR2QZkayFEvQEgiCZ+0QinRfS03EQtY+r XJzmdRarJprfDq4b91Bp5LITT0bwKIAcHsqdvHs/BSlBUP2JgwLi7DHui/kP J9YMMI2nczoQx3ozXFGo3hWWV580dnHVdm4kyvtMGkJ1DCG+uhTmePzyH/Yz Zign0qsVKuse5PBwYsqqmgCCNO8smi2XwM0jGSr7jjoYd/We7ySzgq0vdMdt 0CQ3G2sR/DeyGBvsXDEVZ8LVCaTkevmVe8X8Ky9Z+U25CYV7ZoqTWNX6TBS4 cjGMfbxdBOCXRNRyOUkYLPEeeLmrsKl76bq1nGqY00NNrinjkPdxmxrDp8OP tiw1xKQM5j67Dkm6cbVhSPAyhIKcrGfGiahNMOILYnuEx/TJDQXFBQKBWIqc aamL404CRIWlpy4URDKGIFNOblaX6v1pTgIXe60GOjbNT4iIfSA7sFBMJrWw 7gvlnn4/X4pl7LegwRAMt87ikxom7nd8IBN6VZx0MyFRKPWKVvrFkmR5ZQ5Q R5zDGFLztRACyJruktM/LTfOa/RZYn1B4pqh3Ns7VE+zrMYEjTDix79RC2Au n8eCFIgsYVVpkTQ5RrTFp4BatUsV+LG9RROwq2om83VeXJIGYiVrCrviT+ia CyJF =XmoD -----END PGP SIGNATURE-----

8 21

Re: [tz] Geolocation extension to tzdist
by Karl Petrow Sept. 29, 2016

Sept. 29, 2016

Just signed up for this mail list so please forgive me if my etiquette is bad. There is a node module for this already I have used. https://www.npmjs.com/package/tz-lookup Karl Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

2 1

Re: [tz] tz-2016g.tar.gz and Oracle Java Timezone Updater Tool
by Susan Abraham Sept. 29, 2016

Sept. 29, 2016

Hi Pete, Oracle has not yet released the OJVM patch for 2016g. It is expected by 2nd week of Oracle. Regards, Susan On 9/27/2016 5:30 PM, tz-request(a)iana.org wrote: > Send tz mailing list submissions to > tz(a)iana.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mm.icann.org/mailman/listinfo/tz > or, via email, send a message with subject or body 'help' to > tz-request(a)iana.org > > You can reach the person managing the list at > tz-owner(a)iana.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tz digest..." > > > Today's Topics: > > 1. tz-2016g.tar.gz and Oracle Java Timezone Updater Tool > (Dempsey, Peter) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 27 Sep 2016 11:27:10 +0000 > From: "Dempsey, Peter" <Peter.Dempsey(a)verint.com> > To: "tz(a)iana.org" <tz(a)iana.org> > Subject: [tz] tz-2016g.tar.gz and Oracle Java Timezone Updater Tool > Message-ID: > <53037F6841B154468CE4ADF48141A7F7E9385CF6(a)TLVMBX1.verint.corp.verintsystems.com> > > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > I was wondering where I could a version of the 2016g.tar.gz file that works with the Oracle Java Timezone Updated Tool. I need to test this tool by using the file:// protocol. > > Best regards, > > Pete > > > -- Oracle <http://www.oracle.com> Susan Abraham | Principal Software Engineer, Advanced Resolution Engineer<tel:+9886756903> Oracle Global Customer Service Oracle India Bangalore Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

2 2