- tz - lists.iana.org

Epic fail for DST fallback in hospital health records
by Paul Eggert Nov. 6, 2018

Nov. 6, 2018

Sydney Lupkin reports in today's Kaiser Health News that Epic Systems, a leading system used for hospital health records, cannot handle DST fallbacks such as Sunday's fallback in the US. Lupkin writes: 'Carol Hawthorne-Johnson, an ICU nurse in California, said her hospital doesn’t shut down the Epic system during the fall time change. But she’s come to expect that the vitals she enters into the system from 1 a.m. to 2 a.m. will be deleted when the clock falls back to 1 a.m. One hour’s worth of electronic record-keeping “is gone,” she said.' Apparently competing systems have similar problems. Lupkin writes that many hospitals plan for Cerner (another major system) to be down after a DST fallback as well. Dr. Steven Stack, past president of the American Medical Association, said these DST glitches are "unacceptable", considering that Apple and Google seem to have dealt with seasonal time changes long ago. Although Lupkin didn't say so, credit should be given to the design for the Unix operating system that is the basis for these successes of Apple and Google, as Unix standardized on UTC in the early 1970s; apparently Epic and Cerner (both founded 1979) did not get the message. The moral of this story seems to be: arrange for your medical emergencies to occur some time other than early Sunday in the US. Source: Lupkin S. Like Clockwork: How Daylight Saving Time Stumps Hospital Record Keeping. Kaiser Health News. 2018-11-03. https://khn.org/news/like-clockwork-how-daylight-saving-time-stumps-hospita…

9 17

tzdata2018g.tar.gz failing to install in Java 8
by Carter, Tom Nov. 6, 2018

Nov. 6, 2018

Iana team: I am getting the following when trying to install tzdata2018g.tar.gz using the latest tzupdater.jar (2.2.0) for Java 8. Failed: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_5/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_5/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377) at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191) at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307) at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:153) at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:230) at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:634) Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000 at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173) at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210) at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475) at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399) at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354) ... 5 more Please advise when will this be fixed? Thanks, Tom L Carter Principal Architect: CS/BW, American Airlines Work#: (817) 963-7640 Cell: (972) 849-1416 Coordinates: 4N-5A-53@HDQ2 Meeting Room<https://americanairlines.webex.com/join/Tom.Carter> NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient(s). If you are not an intended recipient, please do not read, distribute, or take action in reliance upon this message. If you have received this in error, please notify me immediately by return email and promptly delete this message and its attachments from your computer.

7 10

[tz-announce] 2018g release of tz code and data available
by Joel da Rosa Nov. 5, 2018

Nov. 5, 2018

Hello! Fail on parser asia TZ (Japan Rule) persist: Using https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz as source for tzdata bundle. Failed: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377) at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191) at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307) at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:153) at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:230) at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:634) Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000 at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173) at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210) at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475) at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399) at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354) My environment: Linux Ubuntu 16.04 java version "1.8.0_191" Java(TM) SE Runtime Environment (build 1.8.0_191-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode) -- Atenciosamente, Joel da Rosa

2 1

Re: [tz] [tz-announce] 2018f release of tz code and data available
by Paul Eggert Nov. 2, 2018

Nov. 2, 2018

On 10/18/18 8:14 AM, Christos Zoulas wrote: > My folks are reporting that java does not like it: > > ERROR: Failed: java.lang.Exception: Failed while parsing file > '/tmp/tz.tmp_2/asia' on line 1655 'Rule Japan 1948 1951 - SepSat>=8 25:00 0 S' > ERROR: java.lang.Exception: Failed while parsing file > '/tmp/tz.tmp_2/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' > Thanks for the heads-up; please try the attached patch. Is there some way your folks can try the development version on GitHub every now and then? That "25:00" has been in the development version since last month and was explicitly called out when the patch was circulated on the mailing list <https://mm.icann.org/pipermail/tz/2018-September/026891.html>. It'd have been nice to catch the glitch before 2018f came out.

14 31

Re: [tz] Time zone confusion in Morocco
by Hicham Boushaba Nov. 2, 2018

Nov. 2, 2018

We Moroccans didn't know about the change also before Friday, our government didn't take the time to neither study nor discuss the matter with us. And the real issue, is that Android devices (maybe iOS devices, I'm not sure) update the tzdb only via a system upgrade/patch, and we know that Android OEMs rarely update their devices, so Moroccans will stay impacted for a long time, and non-tech people don't have the necessary skills to change the timezone manually.

9 12

[PROPOSED] Bring back attribute_pure for getzname
by Paul Eggert Nov. 1, 2018

Nov. 1, 2018

* localtime.c (getzname, getqzname): Bring back ATTRIBUTE_PURE. I was mistaken about GCC not needing this any more, as it’s still needed with GCC 8.2.1 when building with ‘make GCC_INSTRUMENT= CFLAGS='$(GCC_DEBUG_FLAGS)'’. --- localtime.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/localtime.c b/localtime.c index 7b72f9c..ac3790a 100644 --- a/localtime.c +++ b/localtime.c @@ -789,7 +789,7 @@ static const int year_lengths[2] = { ** Return a pointer to that character. */ -static const char * +static ATTRIBUTE_PURE const char * getzname(register const char *strp) { register char c; @@ -810,7 +810,7 @@ getzname(register const char *strp) ** We don't do any checking here; checking is done later in common-case code. */ -static const char * +static ATTRIBUTE_PURE const char * getqzname(register const char *strp, const int delim) { register int c; -- 2.19.1

1 0

Will Morocco switch from +01 to +00 during Ramadan next year?
by Paul Eggert Nov. 1, 2018

Nov. 1, 2018

Maamar Abdelkader wrote: > The 2019 Ramadan period is supposed to be from May 5th to June 4th. > We usually move clocks back the previous week end and come back to the +1 the week end after. > So it supposed to be sunday april 28 and sunday june 12. > > The government does not announce yet the decision about this temporarily change. > > But it s 99% sure that it will be the case, as the previous years. > > A non official survey was done these days, showing that 64% of asked peopke are ok for moving from +1 to +0 during Ramadan. > > https://leconomiste.com/article/1035870-enquete-l-economiste-sunergia-64-de… > > I will share the official decision once it s published. Thanks for the info. I installed the attached patches into the development version on GitHub to implement this. This patch doesn't exactly agree with the dates you specified (for 2019 it guesses falling back Sunday, May 5 and springing forward Sunday, June 9), but these dates are approximate until an official announcement and a methodical guess is better than no guess at all. Java users, please note that this patch uses negative DST in the main and vanguard formats; in rearguard format Morocco stays in the +00 timezone (instead of moving to +01 last weekend) and observes positive DST in every month but Ramadan.

2 2

Time zone confusion in Morocco
by Paul Eggert Nov. 1, 2018

Nov. 1, 2018

Since 2012 Morocco has been switching from +01 (DST) to +00 (standard time) for Ramadan. In an article in today's Morocco World News, Safaa Kasraoui implies (but does not explicitly state) that Morocco will continue this practice even after its time zone switch last weekend from +00 to +01, and thus that Morocco will switch from +01 (standard time) to +00 (presumably DST) during Ramadan next year. If so, we'll have to change tzdb again, this would be another use of negative DST, and I'll bring back my Emacs-based predictions of Ramadan for Morocco. Kasraoui also reports that MP Abdellatif Ouahbi has called on the Moroccan government to release the study that the government said it had conducted on time change. My guess is that no real study was conducted, that the government knew the change would be controversial, and that it announced the change with so little notice because it didn't want controversy to derail the change. The government's main argument for not using DST was the confusion and "tensions and diseases" of switchover, and its main argument for adopting +01 instead of +00 appears to be to smooth out peaks in electricity consumption, though it appears that there is no data to support either argument. As part of the time zone change, the government also changed school timetables so that schools will start at 09:00 instead of 08:00, effectively canceling the time zone change for schools. It said it will make further measures regarding DST, without giving details. Kasraoui reports, "Clocks set by the internet with Moroccan cities selected as the time zone returned to GMT on Sunday and, as of Wednesday, are still showing the wrong time." Presumably this mostly refers to Android and iOS phones; although my US-baseed Android 9 phone is not updated, the Ubuntu desktop that I'm typing this message on is updated. Ubuntu is downstream from Debian which in turn is downstream from tzdb, and the timeline for my desktop update was as follows (all times UTC): 2018-10-27 05:22:45 2018g timestamped 2018-10-27 05:23:38 2018g committed to development version 2018-10-27 12:10:11 2018g available from iana.org 2018-10-27 13:14:23 2018g created for Debian sid 2018-10-27 15:55:08 2018g announced on tz-announce(a)iana.org 2018-10-28 02:00:00 rule change takes effect in Morocco 2018-10-28 21:51:08 2018g created for Ubuntu bionic 2018-10-30 05:23:27 2018g updated on my desktop The update on my desktop was part of routine maintenance. Although Ubuntu is about as good as it gets in this area for a consumer-facing OS, we should be able to even better. Debian beat the deadline but Ubuntu (downstream from Debian) did not, my desktop had the wrong Morocco time for over two days, and my guess is that almost all cell phones and computers in Morocco still have the wrong data for Morocco. Reference: Kasraoui S. Benabdelkader: 68% of Moroccans Wanted an End to Time Changes. Morocco World News. 2018-10-31 13:44 +01. https://www.moroccoworldnews.com/2018/10/256539/

1 0

[PROPOSED] Fix Volgograd label in zone1970.tab
by Paul Eggert Oct. 31, 2018

Oct. 31, 2018

(Reported by Gleb Popov.) * zone.tab, zone1970.tab: Volgograd is now MSK+01. --- zone.tab | 2 +- zone1970.tab | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/zone.tab b/zone.tab index dcb6e1d..368a52d 100644 --- a/zone.tab +++ b/zone.tab @@ -332,9 +332,9 @@ RS +4450+02030 Europe/Belgrade RU +5443+02030 Europe/Kaliningrad MSK-01 - Kaliningrad RU +554521+0373704 Europe/Moscow MSK+00 - Moscow area RU +4457+03406 Europe/Simferopol MSK+00 - Crimea -RU +4844+04425 Europe/Volgograd MSK+00 - Volgograd RU +5836+04939 Europe/Kirov MSK+00 - Kirov RU +4621+04803 Europe/Astrakhan MSK+01 - Astrakhan +RU +4844+04425 Europe/Volgograd MSK+01 - Volgograd RU +5134+04602 Europe/Saratov MSK+01 - Saratov RU +5420+04824 Europe/Ulyanovsk MSK+01 - Ulyanovsk RU +5312+05009 Europe/Samara MSK+01 - Samara, Udmurtia diff --git a/zone1970.tab b/zone1970.tab index 7c86fb6..2729e6e 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -289,9 +289,9 @@ RS,BA,HR,ME,MK,SI +4450+02030 Europe/Belgrade RU +5443+02030 Europe/Kaliningrad MSK-01 - Kaliningrad RU +554521+0373704 Europe/Moscow MSK+00 - Moscow area RU +4457+03406 Europe/Simferopol MSK+00 - Crimea -RU +4844+04425 Europe/Volgograd MSK+00 - Volgograd RU +5836+04939 Europe/Kirov MSK+00 - Kirov RU +4621+04803 Europe/Astrakhan MSK+01 - Astrakhan +RU +4844+04425 Europe/Volgograd MSK+01 - Volgograd RU +5134+04602 Europe/Saratov MSK+01 - Saratov RU +5420+04824 Europe/Ulyanovsk MSK+01 - Ulyanovsk RU +5312+05009 Europe/Samara MSK+01 - Samara, Udmurtia -- 2.17.1

1 0

EU abolition of DST could be pushed back to 2021
by John Wilcock Oct. 30, 2018

Oct. 30, 2018

https://www.bbc.com/news/world-europe-46017347 > "If we aim to do this in 2019, as the [European] Commission suggested, > this will not be supported by the majority of member states," said > Austrian Transport Minister Norbert Hofer, who hosted his 27 EU > counterparts in Graz. > > Allowing until 2021 would help ensure the EU's three existing time > zones did not become a more complicated patchwork, Mr Hofer said. > -- John

1 0