October 2015 - tz - lists.iana.org

Re: [tz] America/Santa_Isabel
by Greg Slayden 27 Oct '15

27 Oct '15

The largest population center in Baja California State south of Ensenada is San Quintín, 190 km south of Ensenada. A new municipality of that name will separate from the large Ensenada municipality on December 1, 2016, and although there are other large localities such as Lazaro Cardenas in that area, San Quintin seems to be the central administrative town. See https://en.wikipedia.org/wiki/San_Quint%C3%ADn,_Baja_California I see conflicting information online about when DST ends there, either November or October. Making contact with locals in that area is likely the best way to find out

5 11

unsubscribe
by Mehdi.Erroussafi＠inwi.ma 27 Oct '15

27 Oct '15

[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 25 Oct '15

25 Oct '15

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 25 Oct '15

25 Oct '15

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 25 Oct '15

25 Oct '15

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 25 Oct '15

25 Oct '15

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 24 Oct '15

24 Oct '15

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 24 Oct '15

24 Oct '15

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 21 Oct '15

21 Oct '15

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 20 Oct '15

20 Oct '15

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