- tz - lists.iana.org

unsubscribe
by Mehdi.Erroussafi＠inwi.ma Oct. 27, 2015

Oct. 27, 2015

[cid:image001.jpg@01D110B0.3DB0CAE0] Elmehdi Erroussafi Manager Core Voice/Data/Vas Direction opérations et maintenance mobile : 0600 000 140 mail : mehdi.erroussafi(a)inwi.ma<mailto:mehdi.erroussafi@inwi.ma> site : www.inwi.ma<http://www.inwi.ma/> imprimer utile préserve l'environnement ________________________________ « Ce message et toutes les pièces y jointes sont susceptibles de contenir des informations confidentielles ou privilégiées, lesquelles ne doivent être reproduites, diffusées ou exploitées sans autorisation. L'intégrité des messages électroniques n'étant pas garantie, WANA CORPORATE décline toute responsabilité dans le cas où ce message aurait été altéré, déformé ou falsifié. Ce message est établi à l'attention exclusive de ses destinataires. Si vous avez reçu ce message par erreur, veuillez le signaler à l'expéditeur et le détruire y compris les pièces jointes. Merci. » -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- « This message and its attachments may contain confidential or privileged information that should not be copied, distributed or used without authorization. As the integrity of emails may not be guaranteed, WANA CORPORATE is not liable for messages that have been modified, changed or falsified. If you have received this email in error, please notify the sender and delete this message and its attachments. Thank you. »

1 0

Re: [tz] Version in zoneinfo files?
by Paul Ganssle Oct. 25, 2015

Oct. 25, 2015

I don't think anyone's stopping you from using old zic to compile newer data. My understanding is that the release version is in the Makefile of all version-2 tzdata files, so nothing would have to change about the tzdata files themselves. You may well have metadata-incompatible zoneinfo files for some time, however, if compiling them with older versions of zic, but I think there's always going to be some lag between the introduction of a new versioning system and reliability in its adoption. On 10/25/2015 01:51 PM, Tim Parenti wrote: > > On 25 October 2015 at 13:26, Paul G <paul(a)ganssle.io <mailto:paul@ganssle.io>> wrote: > > > I think, as Paul E suggests, keeping the version external is a good choice here. It encourages people to use whatever the platform provides to find out the exact, local version information. If anyone knows how to find out what version of tzdata is installed on this macbook I’d love to know :) > > I think this perfectly illustrates the reason why the versioning should be at the zic level and not downstream. > > > There's also the separate matter that tzcode and tzdata are separate and largely independent. Although there have been a few breaking changes to the data format over the years, in principle, there's little reason someone couldn't use a 2014j zic to compile 2015g data, and I suspect that sort of thing actually happens somewhat often. > > -- > Tim Parenti

1 0

Re: [tz] Version in zoneinfo files?
by Guy Harris Oct. 25, 2015

Oct. 25, 2015

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")?

1 0

Version in zoneinfo files?
by Paul G Oct. 25, 2015

Oct. 25, 2015

My understanding is that while the release version e.g. 2014i, etc, is in the tzdata makefile, the binary output by zoneinfo does not have any sort of metadata included. Is this accurate? Is there any way to tell from the zoneinfo output what version was used to generate it? If not, I would like to suggest that a VERSION or METADATA file be added to the zoneinfo output. Otherwise you end up having to bundle your own metadata file along with the zoneinfo (which means that two applications that both consume zic output may each have to bundle their own binary, which can cause problems as two applications with different release cycles go out of sync from one another).

5 6

Re: [tz] Version in zoneinfo files?
by Paul Ganssle Oct. 25, 2015

Oct. 25, 2015

To: Guy Harris <guy(a)alum.mit.edu> 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. (Sorry guy, forgot to Reply-All)

1 0

Scientists, and Journalists and Boomtown Mondays
by Steffen Nurpmeso Oct. 24, 2015

Oct. 24, 2015

Researchers have spotted some curious links between daylight saving and our health, including [2]fewer heart attacks[/2] when the clocks go back. For others the extra hour in bed this weekend [3]is a time to embrace our inner sloth[/3], the undisputed champion of indolence, and a chance to explore our history of laziness. [2] http://theconversationuk.cmail2.com/t/r-l-ztyhlht-iduidjkttk-j/ [3] http://theconversationuk.cmail2.com/t/r-l-ztyhlht-iduidjkttk-t/ [2] says: In 2008, researchers examined the influence of these transitions on the incidence of heart attacks across several years of hospital admissions data. They focused on the two weeks before and after the clocks changed. Worryingly, they found a spike in the number of reported heart attacks after the transition to DST in the spring. In contrast, after moving out of daylight savings time in the autumn this trend was reversed. Worryingly when i walk through the forests in spring (around that time) i see a lot of heart-attacked mice which collapsed while crossing sunny forest roads. Note (just in case you never faced this mystery yourself) it must be sunny and warm for that to happen. I always feel sad when i see those corpses, after six to eight months of starvation and piercing cold, died in the first real warmth of spring! Likewise it seems right now many of us (here in Darmstadt) don't want to see the last leaves fall and prefer the everlasting cold instead ((([4]))). Well. The actual data that backs that story above [5] is supported by the "Swedish Council of Working Life and Social Research, Ansgarius Foundation, King Gustaf V and Queen Victoria's Foundation, and the Swedish Heart and Lung Foundation", and it also reads Our data suggest that vulnerable people might benefit from avoiding sudden changes in their biologic rhythms. It has been postulated that people in Western societies are chronically sleep deprived, since the average sleep duration decreased from 9.0 to 7.5 hours during the 20th century.4 Therefore, it is important to examine whether we can achieve beneficial effects with prolonged sleep. The finding that the possibility of additional sleep seems to be protective on the first workday after the autumn shift is intriguing. It follows frightening talk about work on Mondays, so better read it: Not before Tuesday! Have a nice weekend. [4] https://www.youtube.com/watch?v=1j-8VcGjMxU (Tiger Lillies - Autumn Leaves) [5] http://www.nejm.org/doi/full/10.1056/NEJMc0807104 --steffen

1 0

Re: [tz] Official definition and origin of the term "Central European Time"
by Matt Johnson Oct. 24, 2015

Oct. 24, 2015

Generally speaking, CET = UTC+1, and CEST = UTC+2. Though in some contexts, CET may be used to identify the pair. It's slightly different than the US, as we have the generic term Pacific Time to cover both PST and PDT, but Europe doesn’t have such a generic term. Looking at your implementation, may I suggest that you create a url for time.is/CEST that is always UTC+2, while time.is/CET is always UTC+1. However, you may want to add a link on the CET page that says something like, "Some locations that observe CET in the winter may be currently observing CEST". Keep in mind that while EU countries are aligned, other locations may use CET/CEST but transition on alternate dates or times, and other locations may be on CET all year long. Also consider that CLDR gives "Central European Standard Time" for long standard form, "Central European Summer Time" for the long daylight form, and "Central European Time" for the long generic form. However, it gives the abbreviations "CEST" to the short daylight form, and "CET" to both the short standard and short generic forms. http://www.unicode.org/cldr/charts/28/by_type/timezones.europe.html As you work more with other time zone abbreviations, you're going to find many other inconsistencies and ambiguities. CST having 5 different interpretations, etc. https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations -----Original Message----- From: tz-bounces(a)iana.org [mailto:tz-bounces@iana.org] On Behalf Of Even Scharning Sent: Friday, October 23, 2015 11:52 AM To: Time Zone Mailing List <tz(a)iana.org> Subject: [tz] Official definition and origin of the term "Central European Time" Is there an official definition of the term "Central European Time" (CET), specifically which UTC offset(s) it refers to? If there is no official definition, where did the term originate from? I asked the information desk at the EU (Europe Direct) to help me find links to relevant legislature, but their reply was that term CET is "not regulated at a EU level, but internationally". All credible sources I have found, say that CET is a constant UTC+1. The closest thing I have found to an authoritative document, is the German Time Act from 1978. It says: "Legal time is Central European Time. It is defined as Coordinated Universal Time plus one hour." There is no reference to the origin of this definition, and no information of whether anyone other than the Germans agree on this definition. http://www.cl.cam.ac.uk/~mgk25/time/zeitgesetz.en.html On the EU's web pages (for instance http://europa.eu/contact/index_en.htm) times are usually given in CET, not CEST (Central European Summer Time), even though daylight saving time is currently observed. Google gives a few hundred thousand results for CET on europa.eu, and numerous of these results are hits on dates in the daylight saving time period. I think it makes more sense to define CET as alternating between UTC+1 (standard time) and UTC+2 (when DST is observed). (See http://time.is/CET for a more elaborate definition.) This is in line with for instance the US time zones Pacific Time and Eastern Time, which refer to the time currently observed, whether it is standard time or daylight saving time. Even Scharning Time.is - exact time for any time zone http://time.is/

2 1

Windows time zone update
by Matt Johnson Oct. 21, 2015

Oct. 21, 2015

Not tzdb related per se, but interested parties on this list may like to know that Microsoft has released a hotfix for Windows operating systems to address DST changes in Fiji and Turkey, and to add the new time zone for North Korea. https://support.microsoft.com/en-us/kb/3093503 These are essentially the same changes as made in tzdb 2015g and 2015f for Pacific/Fiji, Europe/Istanbul, and Asia/Pyongyang. Affected Windows computers should update as soon as possible, as both Fiji and Turkey had DST changes that would otherwise occur on October 25th. Regards,Matt JohnsonMicrosoft

1 0

Time zones get in the way of Romanian power trading
by Paul Eggert Oct. 20, 2015

Oct. 20, 2015

ANRE, the energy regulator in Romania, has an interesting way of trading electric power. Its power exchange operates on Central European Time, whereas its over-the-counter platform operates on Eastern European Time. This is because the power exchange is part of the 4M market (the Czech Republic, Hungary, Romania, and Slovakia) which has standardized on CET, whereas the OTC platform is based on the local time in Romania. As a result, a participant who trades a day ahead on the Romanian OTC platform can be caught out of balance if they attempt to clear their position on the exchange. ANRE says the cost of shifting their OTC platform to CET would exceed the benefits of simpler access to the markets. In the meantime, it would seem that there are interesting time-zone-based arbitrage opportunities in Romanian power trading (or maybe opportunities for anti-arbitrage? :-). These are all 24-hour markets. Dumb question: why don't they standardize on UTC? Udubasceanu S. Romanian regulator to maintain time-zone split across power trading platforms. ICIS 2015-10-15 <http://www.icis.com/resources/news/2015/10/15/9933560/romanian-regulator-to…>

3 2

Different tzdata-latest.tar.gz files returned from different servers
by David Kyes Oct. 20, 2015

Oct. 20, 2015

Hello, It appears cache1.lax.icann.org is still returning the previous 2015f tzdata file when requesting the tzdata-latest.tar.gz from www.iana.org. I have been receiving 2 different responses for the tzdata-latest.tar.gz depending on which icann.org server handles the request. cache1.lax.icann.org is responding with the 2015f tzdata file and "cache1.lax.icann.org" is returning the 2015g. Below are network traces which show the difference in X-Cache-Host , Content-Length and Last-Modified response headers. Opening the Makefile confirms the different versions. Thank you, David Kyes cache1.lax.icann.org =========================== GET https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz HTTP/1.1 User-Agent: Fiddler Host: www.iana.org HTTP/1.1 200 OK Last-Modified: Tue, 11 Aug 2015 02:02:03 GMT Vary: Accept-Encoding content-type: application/x-gzip Cache-Control: public, max-age=3600 Content-Length: 298815 Accept-Ranges: bytes Date: Sat, 10 Oct 2015 01:32:42 GMT Connection: keep-alive Server: Apache X-Cache-Host: cache1.lax.icann.org X-Cache-Hits: 51399 ========================== Makefile VERSION= 2015f ========================== ========================== cache2.lax.icann.org ========================== GET https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz HTTP/1.1 User-Agent: Fiddler Host: www.iana.org HTTP/1.1 200 OK Last-Modified: Thu, 01 Oct 2015 15:09:07 GMT Vary: Accept-Encoding content-type: application/x-gzip content-encoding: identity Cache-Control: public, max-age=3600 Content-Length: 300363 Accept-Ranges: bytes Date: Sat, 10 Oct 2015 00:09:21 GMT Connection: keep-alive Server: Apache X-Cache-Host: cache2.lax.icann.org X-Cache-Hits: 72168 ========================== Makefile VERSION= 2015g

3 2

question about SHA512 when using tzdata
by gerar.moisset＠orange.com Oct. 19, 2015

Oct. 19, 2015

Hello. Is it possible to have a howto procedure ot use SHA-512 checksums when using tzdata? I am getting some errors when trying to update our java, like this, /opt/jdksun64/1.7.0_71/bin/java -jar /opt/jdksun64/1.7.0_71/jre/lib/tzupdater.jar -f -l http://localhost:81/tzdata2015g.tar.gz -v It returns, tzupdater tool would update with tzdata version: tzdata2015g Error encountered while downloading https://javadl-esd-secure.oracle.com/update/tzupdater/tzdata2015g.tar.gz.sh… And I don't see very well how to use your SHA-512 checksums procedure. Gérard Moisset gerar.moisset(a)orange.com<mailto:gerar.moisset@orange.com> _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

5 8

Bloomberg open-source tzdata implementation
by Andrew Paprocki Oct. 16, 2015

Oct. 16, 2015

For anyone interested, a new implementation was recently open-sourced. Bloomberg's timezone library including tzdata parser was part of the recent 3.0 release of the BDE C++ library. This is built on top of the previously released date/time vocabulary types. High-level utility for performing conversions, TimeZoneUtil (doxygen): http://bloomberg.github.io/bde/group__baltzo__timezoneutil.html All baltzo:: component docs: http://bloomberg.github.io/bde/group__baltzo.html All baltzo:: component code: https://github.com/bloomberg/bde/blob/master/groups/bal/baltzo -Andrew @ Bloomberg

2 1

Re: [tz] [Tzdist] Timezone in Brazil
by Lester Caine Oct. 12, 2015

Oct. 12, 2015

On 12/10/15 17:55, Paul Eggert wrote: >> you can't use tzdb for reliable conversions prior to 1970! > > Not so. Absolutely you can use tzdata, for places like Europe/London in > 1915 where the information has been checked and double-checked. True, > tzdata is unrelable for *some* locations before 1970, but it's also > unreliable for some locations *after* 1970. If you want guaranteed > reliability, you're not going to find it in tzdata, nor in any other > database out there. Europe/Jersey and Europe/Guernsey did not follow London during the war and other backzone aliases also vary across Europe in that period Europe/Belfast followed Ireland pre 1968 and like Europe/Isle_of_Man switched to a standard time at a different date to the rest of the UK. All only little point's, but important differences in the pre 1970 chronology! These differences are validated data ... but missing if a distribution simply switches backzone off and while yes some backzone material is unverified, this particular section is very much verified. So how does one recognise that those aliases are returning the correct pre-1970 data and not just mirroring Europe/London or one of the other generic European rule sets? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

1 0

[PATCH] * checktab.awk: Typo fix for error message
by Gilmore Davidson Oct. 12, 2015

Oct. 12, 2015

Hi, while looking into the make scripts I found a minor typo in one of the error messages. s/sname/same/ Cheers, Gil

2 1

Timezone in Brazil
by MARCIO IKEDA Oct. 11, 2015

Oct. 11, 2015

This is Marcio Ikeda from LG Electronics in Brazil. Nice to meet you! I would like to know if there are some background history for timezones in Brazil. It seems that Brasilia city which is the capital, is only treated as a metaZone and not a timeZone. I would like to know if are there some discussions on why America/Brasilia is not in the list. And if It is possible to include it. This is causing people from QA here to question this. Thank you! Marcio Ikeda Software Engineer | UIFW - LGESP SCA R&D Lab Office: + 55 11 2202 5339 Mobile:+ 55 11 9 9966 6457 E-mail: marcio.ikeda(a)lge.com [cid:image001.jpg@01D101F6.1F9FE450] LG ELECTRONICS DO BRASIL Av. Dr. Chucri Zaidan, 1170 - 10º andar - CEP 04583-110 - São Paulo/SP www.lge.com/br<http://www.lge.com/br> [cid:image002.jpg@01D101F6.1F9FE450]

7 15

Re: [tz] America/Santa_Isabel
by Steve Jones Oct. 9, 2015

Oct. 9, 2015

At 07:51 AM 10/8/2015, Arthur David Olson wrote: >We might expect that if the legislative intent was for the entirety >of Baja California to use the U. S. rules, the legislation would >have been written more simply. > >That being said, it's certainly possible (or even probable) that de >facto the entirety of Baja California uses U. S. rules, regardless of de jure. > >Providentially, we're coming up on the days when a few international >phone calls (or, if possible, monitoring radio or TV stations) can >shed light on the matter. Not sure if this casts light or mud on the issue, but last year (Feb '14) I contacted a business on Isla Cedros (which is in Baja) about the local time, and received this reply (relevant passage underscored): >Mr Jones >Thank you for coming to us for the answer. >Cedros island is governed by the Baja California State, therefore >most of the time it has the same time zone Pacific shared by >California. But, thanks to bureaucrats sitting behind their desks >with nothing better to do than to complicate the lives of their >citizens ....... Sorry...... sometimes after the time change in the >US the time zone is different than California, but is not for more >than a week, when its similar to Mountain time/ Baja Sur..... I >know, what a pain.... >There is no ferry services for passengers from Bahia Tortugas to Cedros. >I hope this helps. >Salud! >Jose Angel Sanchez >Cedros Outdoor Adventures So it sounds like the actual implementation may not extend all the way down to the Baja/Baja Sur border. Regards, Steve Jones

4 5

Re: [tz] America/Santa_Isabel
by Arthur David Olson Oct. 8, 2015

Oct. 8, 2015

The use of Santa Isabel does indeed seem to be an error. I see, though, that San Felipe, like Santa Isabel, is part of the Mexicali municipality; San Felipe may also use U. S. rules. The "northamerica" file's quotation of the relevant decree mentions "los municipios de Tijuana y Mexicali" but only "la Ciudad de Ensenada" (rather than "el municipio"); we may get to use the largest city in the Ensenada municipality that's south of the city of Ensenada. That seems to be Rodolfo Sánchez Taboada (Maneadero) (22,957); the normal 14-character limit would suggest using Maneadero; it seems to have a larger population that San Felipe (16,702). Lázaro Cárdenas (16,294) is substantially farther south and thus likelier to use Mexican rules; some 14-character-limit creativity would be required. Of course if we were lucky we'd discover that Santa Isabel actually uses Mexican rules.-S --ado https://en.wikipedia.org/wiki/San_Felipe,_Baja_California https://en.wikipedia.org/wiki/Ensenada_Municipality

3 4

America/Santa_Isabel
by Matt Johnson Oct. 8, 2015

Oct. 8, 2015

Does anyone know why America/Santa_Isabel was chosen to represent the portion of Baja California (Mexico) that follows Mexican DST rules? Santa Isabel is just as close to the US border as Tijuana and Mexicali, which are in the America/Tijuana zone. According to Wikipedia ( https://en.wikipedia.org/wiki/Baja_California ) "Over 75% of the population lives in the capital city, Mexicali, in Ensenada, or in Tijuana. Other important cities include San Felipe, Rosarito and Tecate." Of those, it would seem Ensenda and San Felipe would be the only cities not near the US border, and my understanding is that Ensenada follows the US rules. Wouldn't then America/San_Felipe be a better choice?

2 2

Fwd: Turkey delays winter time
by Fatih Oct. 5, 2015

Oct. 5, 2015

Hi, its officialy announced now by ministry of energy. Turkey delays winter time to 8th of November 04:00 http://www.aa.com.tr/tr/turkiye/yaz-saati-uygulamasi-8-kasimda-sona-erecek/… <https://t.yesware.com/tl/a9ae0329641b7dd629a1f9fbd15b34b7a31e117f/a9aeca165…> (Turkish Official News Agency) Best regards. Fatih, WorldClock.com™ <https://t.yesware.com/tl/a9ae0329641b7dd629a1f9fbd15b34b7a31e117f/a9aeca165…> 2015-09-20 6:04 GMT+03:00 Paul Eggert <eggert(a)cs.ucla.edu>: > After looking around a bit, I found a news article dated September 8 on > the topic. I wonder why the news took so long to be known more broadly? > Anyway, attached is a proposed patch to match the many news sources that > talk about this. Although I have installed this in the experimental > version on github, I would prefer confirmation from a more-official source > before doing a tzdata release. >

3 2

Asia/Nicosia
by Steven Nicolaou Oct. 3, 2015

Oct. 3, 2015

Hi, I would like to propose that Asia/Nicosia move to Europe/Nicosia. The Asia file makes this statement: # Classically, Cyprus belongs to Asia; e.g. see Herodotus, Histories, I.72. # However, for various reasons many users expect to find it under Europe. While I appreciate the nod to classical antiquity, its classification under Asia is wholly irrelevant today. This statement appears to trivialize the "various reasons" why "many users" tend to expect it under Europe. . Cyprus is a European country . The culture is decidedly Europe-facing . It is a member state of the European Union . Its currency is the Euro . It has participated in the Eurovision Song Contest since 1981 . Its time zone is Eastern European Time (EET) . The predominant culture and language is Greek . The earliest historical reference to Cyprus in the 15th century BC was in Mycenaean Greek . The Asia file itself even mentions this: "# IATA SSIM (1998-09) has Cyprus using EU rules for the first time." There is nothing Asian about Cyprus today. Nobody in the country attempting to set the local time zone is going to look for it under Asia. If we don't find it under Europe, we assume it was erroneously omitted. Steven

3 2

Last weekend's daylight-saving confusion in Morocco
by Paul Eggert Oct. 1, 2015

Oct. 1, 2015

Thomas Savage reports confusion in Morocco last weekend involving daylight saving time. See: Savage T. Quelle heure est-il vraiment au Maroc? Telquel.ma 2015-09-30. http://telquel.ma/2015/09/30/quelle-heure-il-vraiment-au-maroc_1464578 Savage quotes last month's confusion on the tz mailing list over whether Morocco's fallback transition this year would be Sept. 27 (as an incorrect news report would have it) or Oct. 25 (the official date), and speculates that this confusion led to many electronic devices in Morocco to misbehave on Sept. 27. In thinking about the failure symptoms, though, I guess a more plausible explanation is that the malfunctioning devices were using the equivalent of a tz release somewhere from tzdata 2012c (dated 2012-03-07) through 2013g (dated 2013-09-30), as these older releases predicted that Morocco would fall back the last Sunday in September -- a prediction that was correct in 2012 but incorrect in 2013 through 2015.

1 0

[tz-announce] 2015g release of tz code and data available
by Paul Eggert Oct. 1, 2015

Oct. 1, 2015

The 2015g release of the tz code and data is available. It reflects the following changes, which were either circulated on the tz mailing list or are relatively minor technical or administrative changes: Changes affecting future time stamps Turkey's 2015 fall-back transition is scheduled for Nov. 8, not Oct. 25. (Thanks to Fatih.) Norfolk moves from +1130 to +1100 on 2015-10-04 at 02:00 local time. (Thanks to Alexander Krivenyshev.) Fiji's 2016 fall-back transition is scheduled for January 17, not 24. (Thanks to Ken Rylander.) Fort Nelson, British Columbia will not fall back on 2015-11-01. It has effectively been on MST (-0700) since it advanced its clocks on 2015-03-08. New zone America/Fort_Nelson. (Thanks to Matt Johnson.) Changes affecting past time stamps Norfolk observed DST from 1974-10-27 02:00 to 1975-03-02 02:00. Changes affecting code localtime no longer mishandles America/Anchorage after 2037. (Thanks to Bradley White for reporting the bug.) On hosts with signed 32-bit time_t, localtime no longer mishandles Pacific/Fiji after 2038-01-16 14:00 UTC. The localtime module allows the variables 'timezone', 'daylight', and 'altzone' to be in common storage shared with other modules, and declares them in case the system <time.h> does not. (Problems reported by Kees Dekker.) On platforms with tm_zone, strftime.c now assumes it is not NULL. This simplifies the code and is consistent with zdump.c. (Problem reported by Christos Zoulas.) Changes affecting documentation The tzfile man page now documents that transition times denote the starts (not the ends) of the corresponding time periods. (Ambiguity reported by Bill Seymour.) Here are links to the release files: ftp://ftp.iana.org/tz/releases/tzcode2015g.tar.gz ftp://ftp.iana.org/tz/releases/tzdata2015g.tar.gz The files are also available via HTTP as follows: http://www.iana.org/time-zones/repository/releases/tzcode2015g.tar.gz http://www.iana.org/time-zones/repository/releases/tzdata2015g.tar.gz As usual, links to the latest release files are here: http://www.iana.org/time-zones/repository/tzcode-latest.tar.gz http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz ftp://ftp.iana.org/tz/tzcode-latest.tar.gz ftp://ftp.iana.org/tz/tzdata-latest.tar.gz Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit 6d00980f1ff2ac665f3de027c79faacf4f26d1b0 dated Thu Oct 1 01:43:59 2015 -0700 and tagged '2015g' in the experimental github repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 44da833da3afdb82636a953785372bb4c765e61e40d700da40b46ab70007ebdbde4d480e10b87cbb36c45eaaffcaa6b9894375e2f553b7d16655dc167cd4a11f tzcode2015g.tar.gz ad7de0e3e8753861d260f0fcbcbca327516a4dc826f7659370a7fb979e6154f1a26b23d2609acf6e1790c8c59da0b76c42f4a94bf361409c1460f6a8ffa6f879 tzdata2015g.tar.gz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJWDP2cAAoJEO2X6Q5iqn40XHkP/2QXgHEJuj0XQaMy0Wy5RZQT vrWN0z8zfO5J5LBv03cjNmeYsmQvN2Sy2f2wNESo0GUm4qunujQW/Y0qKRn1Hnwz +nRNrWFmGqYFANapR9emUorucl+l24VQUkBc7piAkVZU1ouEsksHss3uYnNfCwyl L/2Vc7KY07/N6QyAmdiSp3AKWu0CnItsdzRyy99amj/7d3QKOrMvAxiGeAe7V1P7 W0Ath56JxTnuHMCOawHTUtzBt13qjZ7cFBHsOb4xclrZ3ryNnu3Pzd94bxeP3NGp 4AkfTcgo0mYrIMAuf/b40xbZJBcZNzkbCbZ5iE2XMVPToMPL/I2e4C+rZP+Ot7fv TkChGvv9ridmeEqTIVCtOXyR8AQGgGCNpMKsEE1Py5Lkx63gMBtxkdSXOZXi+QZ5 UljSY8RT2vQ81eailUGQRjtLyTGlhmel3yioD+aXbJyiYVrkSOfQ/En5wcIMtWqm DwgTsaIX70gT+1CUVLixdEdUSKhd9p+Voypvf14xIcAYqii08jlvd8AeR1IY5+Uz yr09gX7esp3B+9HgRgkH82R5nqstWbuc/5sVlnreM+7obnc5/QWPHoDUWgJQO7sk R/Cb6Kc32UrfZwAmy4rRoOA4uTsYvIazqoaiuE/sfNSRUD3R4rOQPDxXMx6m/kbf bGwkIeBRSuC9nmVI40G+ =U0wm -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJWDP2cAAoJEO2X6Q5iqn40AUcQAJQI8NTDYuLOHrsnnbpdmmF4 DG91kmznvXK+S5AjXbeUtSyoLL/XJwq2Io25u7OKaH5O+9/HgcN1Y1afHtSHAhEB i8Mg0sfvV6IJRpIKA/++6VILRqgKCOLzxyggk7dZbdAQQdvl4z2qmWR/5m5nJ7K/ seE+sTsJ1j6ra77APK+ffauoN7ArFweMmpVC3tBSkBpCXYPPuGToBfGxFo3gnpni Kqv/ahjlRNUcmyw/ALbCdBEL40k7bxftL6uM0BbapV2GYVU+UTz+isVStHmg3P5V TS1gpgmjKMDBh4P0UEiaVhtsI+EBNU1YW/o8c2xdoGuz6qgbxeeMyrPxUQu2qb0w LDHovfsIhoB2YNTGK2M+1aio2lkhcV+AX7241RuGxiP/n92c+6SPGlY7o69XQqaC i58/AjS3a6E7yYgb+birN+/Yi0KzxWwI6nJMxlLSfc9yFZREf9nCd+7YPcSSJJIO 3fbsFNJPoPa36hfMH83L0rmyphpQEU2+46+BboqQhL9ULV4QhYiNCeXXyZm1ptDl BMyjxh2mO+sPDE47xyI7tsl94dzbgmWMSQp74SlFLDPaK065x5U+Z8437oiMip5K rhVXzr/vyrzX/Anyok05i3lmY3iAFyBIFuv7s93nr0SnrZDjCDq6FafLSOnvIhD7 4R6azOsK4h1HbCxswUCK =yiad -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

Fiji change exposed Y2038 bug in localtime.c
by Paul Eggert Oct. 1, 2015

Oct. 1, 2015

The recent change to the Pacific/Fiji data added a transition from +1300 to +1200 at 2018-01-17 03:00 local time, which is just before the maximum 32-bit signed time_t value. Previously, that transition was just after the 32-bit boundary. This change exposed a curious bug in the interaction between zic and localtime.c on platforms with signed 32-bit time_t. For the benefit of older systems, zic outputs explicit transitions for years in the range 1900 through 2037, relying on the POSIX-TZ-style string (for Pacific/Fiji, "FJT-12FJST,M11.1.0,M1.3.0/3") at the end of the tzfile for transitions outside that range. Although newer versions of localtime.c should use the POSIX-TZ-style string for time stamps in the year 2038, if time_t is a signed 32-bit integer these localtime.c versions mishandle Fijian time stamps from 2038-01-16 14:00:00 through 2038-01-19 03:14:07 UTC. This bug is fixed by the attached patch. I discovered this bug during release testing, and will squeeze the attached patch into the next tz release which I plan to make shortly. It strikes me, though, that perhaps zic should be changed too, to better accommodate buggy localtime implementations. If the zic cutoff for old-style transitions is at 2038-01-19 03:14:08 UTC, rather than at 2038-01-01, buggy localtime code should do the right thing. I don't want to install such a change into zic without some thought and/or discussion and/or testing, though; it can wait until a later release.

2 2

isstd and isgmt effect
by Jason Johnson Sept. 30, 2015

Sept. 30, 2015

Hello all I'm writing some software that deals with dates and I parse Olson files to get time zone information. In the tzfile man page, both entries say that they are used for handling POSIX-style environmental variables? Does that mean that I can ignore those values and assume the transition times are just UAT? I couldn't find any documentation on exactly how to handle these values. The nearest thing I found was the Unix time library which seems to make an adjustment based on one setting, but it wasn't clear if this is done in general or if this was part of some specific handling. Thanks for any help you can provide. Jason

3 7

Turkey delays winter time
by Fatih Sept. 30, 2015

Sept. 30, 2015

Hi All, According to news published an hour ago government (Turkey) will postpone end of summer time to 8th of November due to the security issues related with the national election that will be held on 1st Nov. I will confirm from the government agency soon. Best regards. Fatih, WorldClock.com™ <https://t.yesware.com/tl/a9ae0329641b7dd629a1f9fbd15b34b7a31e117f/81cac01ff…>

9 14