- tz - lists.iana.org

Switching to DST in Australia could save Koalas
by Eliot Lear Nov. 23, 2016

Nov. 23, 2016

The problem isn't the Koalas telling time, but humans being on the road at certain times... http://www.latimes.com/science/sciencenow/la-sci-sn-daylight-savings-koalas…

1 0

[PATCH] * NEWS: Add "Briefly:" section.
by Paul Eggert Nov. 23, 2016

Nov. 23, 2016

--- NEWS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/NEWS b/NEWS index 1682709..e018862 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,8 @@ News for the tz database Unreleased, experimental changes + Briefly: Saratov, Russia moves from +03 to +04 on 2016-12-04. + Changes to future time stamps Saratov, Russia switches from +03 to +04 on 2016-12-04 at 02:00. -- 2.7.4

1 0

Re: [tz] Regarding Turkey DST change
by Brian Inglis Nov. 23, 2016

Nov. 23, 2016

On 2016-11-22 13:24, Meno Hochschild wrote: > Am 22.11.2016 um 19:06 schrieb Brian Inglis: >> On 2016-11-22 10:27, Paul Eggert wrote: >>> On 11/22/2016 03:18 AM, Peddi, Radhika (Radhika) wrote: >>>> I am using tzdata along with joda. >>> If the 'date' command works but Joda does not, it must be a Joda >>> problem and not a tzdata problem, so I suggest looking for Joda >>> support. http://www.joda.org/joda-time/ >> Joda runs on Java which has tzupdater problems, so the OP should >> read recent threads and the Oracle page on the Java tzupdater to >> update Java time zones and see correct time, update your JDK/JRE >> to a current release, or submit a TAR to Oracle support. >> Also the OP should note on the Joda page that the Joda API has >> been incorporated into the Java SE 8 java.time class and Joda >> time now deprecates using itself. > Two corrections: > a) Joda Time has nothing to do with tzupdater tool distributed by > Oracle but manages its own independent tz data repository which is > based on analysis of tzdb-sources. > b) The Joda API has NOT been incorporated into Java SE 8 but only > inspired it. Both APIs are really different. > If something with Joda tz-interpretation might be wrong then someone > could check it via Jon Skeets tz-validation-project. But I rather > suspect that there was an outdated Joda-version. The newest version > 2.9.6 is declared to support tzdb-version 2016i. Two problems: - one language product with two sources of time information - no wonder the OP is confused why their time is wrong: perhaps you could post how the OP can correct their Joda time, walk them thru difficulties that may be encountered in http://www.joda.org/joda-time/tz_update.html; - Joda time says the project is finished, and advises migration to Java SE 8 java.time, so it may not be reasonable to expect prompt future releases or tz updates. Like Adobe products, Java has become such a source of security holes and vulnerabilities requiring frequent updates, blocked by various products, that it's safer to uninstall them, eliminate the annoyances and vulnerabilities, and do without what they provide, or use alternatives that don't suffer the same issues. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

1 0

[Russia] Saratov region is moving to UTC+4 at [preliminary] Nov 27, 2016
by Yuri Konotopov Nov. 22, 2016

Nov. 22, 2016

Hello. Today Russian Duma has approved in 1st read (of 3) Law project №1058438-6 that will move Saratov region to UTC+4. Project card: http://asozd2.duma.gov.ru/main.nsf/%28SpravkaNew%29?OpenAgent&RN=1058438-6&… Preliminary date of change is November 27, 2016. As I think new timezone "Europe/Saratov" should be created in tzdata. I will inform you as soon as President will approve Law project. -- Best regards, Yuri Konotopov

4 16

Re: [tz] Regarding Turkey DST change
by Paul Eggert Nov. 22, 2016

Nov. 22, 2016

On 11/22/2016 03:18 AM, Peddi, Radhika (Radhika) wrote: > I am using tzdata along with joda. If the 'date' command works but Joda does not, it must be a Joda problem and not a tzdata problem, so I suggest looking for Joda support. http://www.joda.org/joda-time/

2 1

Regarding Turkey DST change
by Peddi, Radhika (Radhika) Nov. 22, 2016

Nov. 22, 2016

Hi, Could you please tell me whether Turkey DST changes are fixed in tzdata or not? If fixed could you please let me know which tzdata*.tar.gz contains the changes? I have downloaded the latest one available on https://www.iana.org/time-zones. However still UTCOffString value showing as +2.00 instead of +3.00 for November dates. Thanks & Regards, Radhika Peddi|Avaya India Pvt. Ltd.| Wing 'A', Level -5, Tower-11, Cybercity, Magarpatta City, Hadapsar | Pune, 411028|India Voice +91 20 4101 8311| Email: rpeddi<mailto:rpeddi@avaya.com>@avaya.com [Please consider the environment before printing this email]|7 Switch off POWER |[cid:image008.jpg@01CD293C.65903AA0] Save Water |q RECYCLE |P PRESERVE trees |

4 7

[PATCH] Minor changes to iso3166.tab
by Jiri Bohac Nov. 17, 2016

Nov. 17, 2016

As noted in the file, the table intentionally differs from the ISO 3166 English names, mostly using even shorter names than the official short name. In a few cases, it seems to be out of sync with ISO for no good reason: Official changes in ISO, where new is same length or shorter than original: Cape Verde -> Cabo Verde Czech Republic -> Czechia UTF-8 now used elsewhere, so why not for Curaçao: Curacao -> Curaçao No good reason to differ from the standard?: Macau -> Macao Personally, I would also change "Britain" to "United Kingdom", I think it's where people would look first. But it would go from shorter to longer, so I did not include it in the patch. It's still much shorter than many other names. Would "United Kingdom" make sense here? --- iso3166.tab | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/iso3166.tab b/iso3166.tab index 7a8df2c..0e07afd 100644 --- a/iso3166.tab +++ b/iso3166.tab @@ -74,11 +74,11 @@ CN China CO Colombia CR Costa Rica CU Cuba -CV Cape Verde -CW Curacao +CV Cabo Verde +CW Curaçao CX Christmas Island CY Cyprus -CZ Czech Republic +CZ Czechia DE Germany DJ Djibouti DK Denmark @@ -170,7 +170,7 @@ MK Macedonia ML Mali MM Myanmar (Burma) MN Mongolia -MO Macau +MO Macao MP Northern Mariana Islands MQ Martinique MR Mauritania -- Jiri Bohac <jbohac(a)suse.cz> SUSE Labs, SUSE CZ

6 11

Hungary considers moving to +02 year-round
by Paul Eggert Nov. 17, 2016

Nov. 17, 2016

A bill to put Hungary on permanent EET (+02) has passed a parliament committee unanimously. The full parliament is scheduled to vote on it next week. Presumably this would require coordination with the EU, which may mean delays before the change would take effect. See: End of Hungaro-pessimism? - the times they are changing in the Hungarian Parliament. Hungary Today 2016-11-16. http://hungarytoday.hu/news/may-end-hungaro-pessimism-time-changing-questio… Horváth A. Vége az óraátállításnak? Magyar Nemzet 2016-11-16. http://mno.hu/gazdasag/vege-az-oraatallitasnak-1371621

1 0

Turkey ZoneInfo
by Sundeep Dasari Nov. 16, 2016

Nov. 16, 2016

Hi Iam trying to extract turkey zoneinfo from "tzdata2016i.tar.gz" package and is not successfully. I have done the following to extract turkey zone info: zic -d ./mytemp/ asia zic -d ./mytemp/ europe Turkey should be either in Europe or in Asia. Please provide me with your support in this regard. -- Thanks Sundeep.

3 2

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

Nov. 12, 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

"impossible" glitch right at the DST changeover: it had to happen
by scs＠eskimo.com Nov. 11, 2016

Nov. 11, 2016

The mother in this story says she had a hard time "wrapping her head around it", but readers of this list will have little trouble: "Twins' Daylight Saving Time Birth Results in Bizarre Age Twist" http://abcnews.go.com/Lifestyle/twins-daylight-saving-time-birth-results-bi… Yes, one twin was born on the early morning of November 6 at 1:39, and his little brother was born 31 minutes later, at 1:10.

1 0

[PROPOSED] * CONTRIBUTING: Call the GitHub repository "development"
by Paul Eggert Nov. 11, 2016

Nov. 11, 2016

Instead of the old adjective "experimental". --- CONTRIBUTING | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING b/CONTRIBUTING index e40102e..22addd2 100644 --- a/CONTRIBUTING +++ b/CONTRIBUTING @@ -18,10 +18,10 @@ data should contain commentary citing reliable sources as justification. Please submit changes against either the latest release in -<ftp://ftp.iana.org/tz/> or the master branch of the experimental -Git repository. If you use Git the following workflow may be helpful: +<ftp://ftp.iana.org/tz/> or the master branch of the development +repository. If you use Git the following workflow may be helpful: - * Copy the experimental repository. + * Copy the development repository. git clone https://github.com/eggert/tz.git cd tz -- 2.7.4

1 0

Re: [tz] tzdata2016g missing version information
by Dempsey, Peter Nov. 10, 2016

Nov. 10, 2016

Hi, On 09/29/2016 08:590 AM, Eggert, Paul wrote: >Yes, it appears that the Oracle software assumed that the Makefile would have a VERSION line that specifies the version number. That assumption was never documented or guaranteed and is no longer valid. >Perhaps you can work around the problem by modifying the Makefile to say "VERSION = 2016g" (I don't have the Oracle software and so can't easily test this). >We are discussing a better way to address this problem in the future. @Paul Eggert: The Oracle Timezone Update Tool can be downloaded from here: http://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readm…. This tool has two ways of updating the timezone database: 1. Online where the timezone database is downloaded from: -l http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz 2. Offline where the timezone database is loaded locally: -l file:///tmp/tzdata2016g.tar.gz The tzdata file published on the IANA site needs to include the VERSION information so that this tool can work. When do you think this can be provided? I need to test the Oracle Timezone Updater Tool as soon as possible because I have customers with critical systems dependent on the time zone database. @Susan Abraham: I don't know if you are involved with the Timezone Updater Tool but this tool currently can't update the timezone because the database doesn't contain the VERSION information. @Kim Davies: I am adding you to keep you directly in the loop. Best regards, Pete -- This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail.

7 15

Danish Time not UTC
by Brian Inglis Nov. 10, 2016

Nov. 10, 2016

According to the DK NMI DANIAmet: https://daniamet.dk/en/nmi/time-and-frequency/ "The law on time (Law No 83, 29/03/1893) prescribe that the time in Denmark is determined by mean solar time and not the UTC time." -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

6 10

Failed to update tzdata2016g and higer with tzupdater
by Sawadee.Prakayphetchara＠thomsonreuters.com Nov. 9, 2016

Nov. 9, 2016

Hi, We found an issue when try to update timezone with the tzdata2016g.tar.gz - tzdata2016i.tar.gz The problem is that VERSION in the Makefile is not correct, the correct value should match with tz version i.e. 2016i not unknown. # Version number for the distribution, overridden in the 'tarballs' rule below. VERSION= unknown The workaround has been mention in, http://stackoverflow.com/questions/39832866/tzupdater-failing-with-tzdata20… * Update Makefile of http://www.iana.org/time-zones/repository/releases/tzdata2016g.tar.gz: Original value of VERSION variable is unknown and you need to update it to 2016g. * Regenerate tzdata2016g.tar.gz.sha512 file So far we need to apply the workaround on each release. It would be great if you can correct the version in next release? Regards, Sawadee M.

2 1

Timezones - what's so hard?
by Michael Douglass Nov. 7, 2016

Nov. 7, 2016

http://www.gocomics.com/pearlsbeforeswine#mutable_1511244

3 2

[PROPOSED] Port ar usage to POSIX
by Paul Eggert Nov. 7, 2016

Nov. 7, 2016

* Makefile (libtz.a): Use 'ar -rc' instead of 'ar ru', as 'ar -rc' is standardized by POSIX and GNU 'ar' 2.26.1 (Ubuntu 16.04.1) warns about the obsolete form 'ar ru'. --- Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 74b950c..1b714a8 100644 --- a/Makefile +++ b/Makefile @@ -542,7 +542,8 @@ force_tzs: $(TZS_NEW) cp $(TZS_NEW) $(TZS) libtz.a: $(LIBOBJS) - $(AR) ru $@ $(LIBOBJS) + rm -f $@ + $(AR) -rc $@ $(LIBOBJS) $(RANLIB) $@ date: $(DATEOBJS) -- 2.7.4

1 0

Compiler warning in tzcode2016g about SIZE_MAX being wider than int
by Tom Lane Nov. 6, 2016

Nov. 6, 2016

When trying to build 2016g using macOS's current compiler (or, probably, any reasonably late-model version of clang), I get cc -DTZDIR=\"/usr/local/etc/zoneinfo\" -c -o zic.o zic.c zic.c:434:51: warning: implicit conversion from 'unsigned long long' to 'int' changes value from 18446744073709551615 to -1 [-Wconstant-conversion] int amax = nitems_max < SIZE_MAX ? nitems_max : SIZE_MAX; ~~~~ ^~~~~~~~ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/stdint.h:153:20: note: expanded from macro 'SIZE_MAX' #define SIZE_MAX UINT64_MAX ^~~~~~~~~~ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/stdint.h:87:27: note: expanded from macro 'UINT64_MAX' #define UINT64_MAX 18446744073709551615ULL ^~~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. Or in other words, clang is pointing out, quite correctly, that SIZE_MAX won't fit in an int. This doesn't represent a runtime bug because the condition "nitems_max < SIZE_MAX" can never fail, but that just begs the question why have it. I am not aware of any C implementation that has ever had INT_MAX > SIZE_MAX, and surely there are none in use today. I suggest, therefore, a fix along the lines of $ diff -u zic.c~ zic.c --- zic.c~ 2016-09-06 00:39:50.000000000 -0400 +++ zic.c 2016-10-20 13:06:39.000000000 -0400 @@ -431,8 +431,7 @@ return ptr; else { int nitems_max = INT_MAX - WORK_AROUND_QTBUG_53071; - int amax = nitems_max < SIZE_MAX ? nitems_max : SIZE_MAX; - if ((amax - 1) / 3 * 2 < *nitems_alloc) + if ((nitems_max - 1) / 3 * 2 < *nitems_alloc) memory_exhausted(_("int overflow")); *nitems_alloc = *nitems_alloc + (*nitems_alloc >> 1) + 1; return erealloc(ptr, size_product(*nitems_alloc, itemsize)); Alternatively one might think of changing the types of nitems_max and amax to size_t --- but that would just make it even more crystal clear that the "nitems_max < SIZE_MAX" conditional is useless. And if, somewhere, one did find a C implementation in which size_t is narrower than int, that coding wouldn't work at all. Basically I don't see a way of dealing with this that is superior to just assuming that INT_MAX is less than or equal to SIZE_MAX. regards, tom lane

4 8

Daylight saving in Trkey problem
by Caner Aydinbey Nov. 6, 2016

Nov. 6, 2016

Hello. We have linux machine and we have app in there. FOr date command, it shows true date but in spring boot application, we cant get true date. It iss 1 hour later. So we follow guides to update but we cant manage. for example here http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html#… Please suggest us something to do. -- Caner Aydin Software Developer Infoowl Software Solutions & Consultancy +90 542 788 62 64 <%2B90%20530%20960%2035%2053> www.infoowl.net

3 4

Tonga returns to DST on 2016-11-06
by Tim Parenti Nov. 6, 2016

Nov. 6, 2016

Tonga will observe DST from 2016-11-06 02:00 until 2017-01-15 03:00, in line with Fiji. http://mic.gov.to/news-today/press-releases/6375-daylight-saving-set-to-run… This came through as a pull request on the Github repo: https://github.com/eggert/tz/pull/19 Originally submitted patch and proposed follow-up attached. -- Tim Parenti

10 27

zic fails for soft-links-only target volume
by Tom Lane Nov. 4, 2016

Nov. 4, 2016

I received a complaint that zic recently started to fail when the target directory is on a volume that doesn't support hard links. (The complainant is using some weird VMware Fusion setup, but I think this might be true on Windows generally.) It used to go through just fine, creating symlinks instead, but as of 2016g it fails with something like ./zic: link from /home/postgres/testversion/share/timezone/US/Eastern failed: Operation not permitted It appears to me that the problem is that commit 35484e98c broke the case of linking to an existing symlink. This happened because itsdir() was modified to return 2 not 0 for a symlink, but dolink() throws an EPERM error for that, because it wasn't taught about the change. There's no reason to disallow that case, so I propose this patch: diff --git a/zic.c b/zic.c *** a/zic.c --- b/zic.c *************** dolink(char const *fromfield, char const *** 824,830 **** ** there's a fair chance of root running us. */ fromisdir = itsdir(fromfield); ! if (fromisdir) { char const *e = strerror(fromisdir < 0 ? errno : EPERM); fprintf(stderr, _("%s: link from %s/%s failed: %s\n"), progname, directory, fromfield, e); --- 824,830 ---- ** there's a fair chance of root running us. */ fromisdir = itsdir(fromfield); ! if (fromisdir < 0 || fromisdir == 1) { char const *e = strerror(fromisdir < 0 ? errno : EPERM); fprintf(stderr, _("%s: link from %s/%s failed: %s\n"), progname, directory, fromfield, e); BTW, you can test this behavior without needing to have such a volume at hand, by forcing the link() attempt to fail like this: *************** dolink(char const *fromfield, char const *** 840,845 **** --- 840,846 ---- progname, directory, tofield, e); exit(EXIT_FAILURE); } + staysymlink = true; // for testing purposes only!! link_errno = (staysymlink ? ENOTSUP : link(fromfield, tofield) == 0 ? 0 : errno); if (link_errno == ENOENT && !todirs_made) { regards, tom lane

2 7

Why did you rename Russian zone name abbreviations
by Sergei Turchanov Nov. 3, 2016

Nov. 3, 2016

Hello! https://github.com/eggert/tz/commit/1ac038c2c3f25f7211474ae08feb6afb820 e35fe Why did you rename Russian zone name abbreviations? Can you provide a rationale for this change? This change breaks date parsing, etc... With best regards, Sergei Turchanov.

9 22

[PROPOSED] Fix EEST typos in Palestine before 1948
by Paul Eggert Nov. 3, 2016

Nov. 3, 2016

* NEWS: Document this. * asia (Asia/Gaza, Asia/Hebron): Fix typos, to use "EEST" instead of "EET" when abbreviating summer time before 1948. --- NEWS | 8 ++++++++ asia | 4 ++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index da5c2a5..db9f03d 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,13 @@ News for the tz database +Unreleased, experimental changes + + Changes to past time zone abbreviations + + Asia/Gaza and Asia/Hebron now use "EEST", not "EET", to denote + summer time before 1948. The old use of "EET" was a typo. + + Release 2016i - 2016-11-01 23:19:52 -0700 Briefly: Cyprus split into two time zones on 2016-10-30, and Tonga diff --git a/asia b/asia index 67164b3..bb7534a 100644 --- a/asia +++ b/asia @@ -2616,7 +2616,7 @@ Rule Palestine 2016 max - Oct lastSat 1:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Gaza 2:17:52 - LMT 1900 Oct - 2:00 Zion EET 1948 May 15 + 2:00 Zion EET/EEST 1948 May 15 2:00 EgyptAsia EE%sT 1967 Jun 5 2:00 Zion I%sT 1996 2:00 Jordan EE%sT 1999 @@ -2629,7 +2629,7 @@ Zone Asia/Gaza 2:17:52 - LMT 1900 Oct 2:00 Palestine EE%sT Zone Asia/Hebron 2:20:23 - LMT 1900 Oct - 2:00 Zion EET 1948 May 15 + 2:00 Zion EET/EEST 1948 May 15 2:00 EgyptAsia EE%sT 1967 Jun 5 2:00 Zion I%sT 1996 2:00 Jordan EE%sT 1999 -- 2.7.4

1 0

Re: [tz] Why did you rename Russian zone name abbreviations
by Paul Eggert Nov. 3, 2016

Nov. 3, 2016

On 11/02/2016 08:50 AM, turchanov(a)vl.ru wrote: > ... having "date" command output "Wed Nov 2 09:54:58 +10 2016" make > it very difficult to understand where the system is. That's fine, as the "date" command is supposed to be about *when*, not about *where*. > 2. Since the inception of tzdata Olson stated rules for abbreviated > names clearly and unambiguously > (https://github.com/eggert/tz/blob/master/Theory) That old guideline has been deprecated, as mentioned in the Theory file. > 3. I have an impression that you (un-)intentionally confuse an > abbreviated name with a GMT offset. No, the idea is that if there is no common English-language abbreviation for a time zone, tzdata uses a numeric abbreviation instead. > > if one needed a GMT offset it would have used %z-family flags. The problem is not that software needs a GMT offset. It's that software unwisely requires a time zone abbreviation even when no such abbreviation exists in common English-language practice. Although we could simply leave the abbreviation empty in this case, it's more useful to fill it with a placeholder that conveys information to users of applications that unwisely output the abbreviation as-is. > By changing the abbreviated zone name you in effect change the > original full zone name. Why didn't change Asia/Vladivostok to > Asia/+10 as well?! That wouldn't work, as Vladivostok was at +11 before 2014, and at +09 before 2011. Even in the US, where alphabetic time zone abbreviations are common, we wouldn't link America/Indiana/Petersburg to US/Eastern, because Petersburg observed Central Time before 2007. > > 5. You justify your decision to remove abbreviated names by declaring > them as an "invention". Yes. I invented these abbreviations. I didn't use any formal procedure. The (now-deprecated) guideline about them in the Theory file was written after the fact, partly in an attempt to justify them. When I invented those abbreviations, POSIX supported only alphabetic-only abbreviations. Also, I was naive about Russia: I thought that it kept time zones like the US does and that US-style alphabetic abbreviations therefore made sense for it. Nowadays, though, POSIX allows numeric abbreviations, and I know more about Russian practice. From an English-speaking point of view, abbreviations like VLAT are misleading because they imply that there is a time zone at a fixed offset from UTC called "VLAT", which is how abbreviations like "PST", "GMT", and "CET" work. However, abbreviations like "VLAT" do not correspond to fixed UTC offsets, and this is something that English-speakers are typically not expecting or accustomed to. So even if "VLAT" were widely used by Russian speakers, it would still be dubious as an abbreviation in English-language tzdata. I agree that the current situation could be improved, and that there could be a better way to localize time zone abbreviations. I expect this is an effort that should be under the CLDR umbrella, as they're the localization gurus. It may be that we need a better API for getting at localized abbreviations. Certainly the tzcode strftime.c is incomplete here, as it doesn't even support Russian month names, much less genitive-case Russian dates (does CLDR handle that correctly? if not, it should...).

6 10

Latest tzdata2016
by Raymond Kumar Nov. 3, 2016

Nov. 3, 2016

Hi I would like to have a latest patch for tzdata. There were some changes performed on Tonga time zone and we need this patch as Tonga DST is from this week 5th November and we would like to apply this patch on systems. Thanks, Raymond Kumar Head of Billing & Products +6797015315 ________________________________ 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.

2 1