See also: http://www.explainxkcd.com/wiki/index.php/1335 From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Tim Parenti Sent: Wednesday, February 26, 2014 7:05 AM To: David Braverman Cc: tz@iana.org Subject: Re: [tz] xkcd on time I wonder whether/how this will handle the myriad clock changes coming up in March and April. From seeing stuff like this done badly so many times, I've been trained to instinctively assume that it won't; but this is at least moderately interactive, and anyone familiar with xkcd knows that Randall Munroe has done far more clever things in the past. I know I, for one, will be checking back in a couple weeks. =) -- Tim Parenti On 26 February 2014 09:17, David Braverman <david@braverman.org <mailto:david@braverman.org> > wrote: Not strictly on-topic, but close enough, and others on this list may find this amusing: http://xkcd.com/now David Braverman Chicago

Neil, This change has already been discussed and pushed to the experimental repository at https://github.com/eggert/tz/commit/377543e46ebe558844a587a8da9daa4e6c3c2e8d... https://github.com/eggert/tz/commit/4f731021170d5fb8967050bc7522ac3d39258776. There has not yet been an official release. -- Tim Parenti On 26 February 2014 11:01, Neil Masson <NMASSON@uk.ibm.com> wrote:

According to timeanddate.com Turkey is delaying DST this year. I haven't noticed any discussion of this in this forum.

"The Turkish government has just announced that Daylight Saving Time ( *DST* <http://www.timeanddate.com/time/dst/>) will begin at 3:00 a.m. (03:00) *local time*<http://www.timeanddate.com/worldclock/city.html?n=19>on Monday, March 31, 2014, when clocks will be *turned forward one hour* to 4:00 a.m. (04:00). This is one day later than anticipated. *Turkey's normal DST schedule*<http://www.timeanddate.com/worldclock/timezone.html?n=19>is synchronized with *that of most European countries*<http://www.timeanddate.com/news/time/europe-ends-dst-2013.html>. "

http://www.timeanddate.com/news/time/turkey-starts-dst-2014.html

Regards,

*N (Neil) Masson* Java Support Engineer ------------------------------ *Phone:* 44-1962-816763 * E-mail:* *NMASSON@uk.ibm.com* <NMASSON@uk.ibm.com> * Find me on:* [image: YouTube: http://www.youtube.com/user/ibmjtc]<http://www.youtube.com/user/ibmjtc> [image: Twitter: http://twitter.com/ibm_jtc] <http://twitter.com/ibm_jtc> [image: IBM]

Hursley Park Hursley, SO212JN United Kingdom

Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Øyvind A. Holm wrote:

...

This change has already been discussed and pushed to the experimental

...

repository at https://github.com/eggert/tz/commit/377543e46ebe558844a587a8da9daa4e6c3c2e8d and https://github.com/eggert/tz/commit/4f731021170d5fb8967050bc7522ac3d39258776. There has not yet been an official release. Experimetal? I think it would be a great solution to have the official tz database placed in a Git repo somewhere, and GitHub is a nice place to put it. Are there any other official tz repositories somewhere?

The experimental version IS on github. But github is not the best place to manage releases! Only developing the next release. -- 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

Ah, yes; you are correct Øyvind. You can think of https://github.com/eggert/tz as the "official experimental" repository; i.e., the official place where changes are staged; whereas http://www.iana.org/time-zones is currently the only official avenue for full stable releases. -- Tim Parenti On 26 February 2014 13:05, Øyvind A. Holm <sunny@sunbase.org> wrote:

On 26 February 2014 18:29, Lester Caine <lester@lsces.co.uk> wrote:

...

Øyvind A. Holm wrote:

...

Tim Parenti wrote:

...

This change has already been discussed and pushed to the experimental repository at https://github.com/eggert/tz/[...] and https://github.com/eggert/tz/commit/[...] There has not yet been an official release.

Experimetal? I think it would be a great solution to have the official tz database placed in a Git repo somewhere, and GitHub is a nice place to put it. Are there any other official tz repositories somewhere?

The experimental version IS on github. But github is not the best place to manage releases! Only developing the next release.

I agree on that. But it would be nice to have an official "blessed" location where the development happens so we get a full authoritative history of the changes. But it seems as github.com/eggert/tz/ is the most "official" repository at the moment, and based on Paul's history with the project, it seems as the correct place to have it for now. If there should be some changes in that opinion (GitHub getting difficult or something), it's easy to push it somewhere else. I was just wondering if that repo is recognised as the official place where all the good stuff happens, and it looks like that to me.

Regards, Øyvind

On 26/02/2014 16:55, Tim Parenti wrote:

Neil,

This change has already been discussed and pushed to the experimental repository at https://github.com/eggert/tz/commit/377543e46ebe558844a587a8da9daa4e6c3c2e8d and https://github.com/eggert/tz/commit/4f731021170d5fb8967050bc7522ac3d39258776. There has not yet been an official release.

Are we expecting an official tzdata release? If so, any estimates for when it might become available ? Thanks, Sean.

-- Tim Parenti

On 26 February 2014 11:01, Neil Masson <NMASSON@uk.ibm.com <mailto:NMASSON@uk.ibm.com>> wrote:

According to timeanddate.com <http://timeanddate.com> Turkey is delaying DST this year. I haven't noticed any discussion of this in this forum.

"The Turkish government has just announced that Daylight Saving Time (_DST_ <http://www.timeanddate.com/time/dst/>) will begin at 3:00 a.m. (03:00) _local time_ <http://www.timeanddate.com/worldclock/city.html?n=19>on Monday, March 31, 2014, when clocks will be *turned forward one hour* to 4:00 a.m. (04:00). This is one day later than anticipated. _Turkey's normal DST schedule_ <http://www.timeanddate.com/worldclock/timezone.html?n=19>is synchronized with _that of most European countries_ <http://www.timeanddate.com/news/time/europe-ends-dst-2013.html>. "

http://www.timeanddate.com/news/time/turkey-starts-dst-2014.html

Regards,

*N (Neil) Masson* Java Support Engineer ------------------------------------------------------------------------ *Phone:*44-1962-816763* E-mail:*_NMASSON@uk.ibm.com_ <mailto:NMASSON@uk.ibm.com>* Find me on:*YouTube: http://www.youtube.com/user/ibmjtc <http://www.youtube.com/user/ibmjtc>Twitter: http://twitter.com/ibm_jtc <http://twitter.com/ibm_jtc> IBM

Hursley Park Hursley, SO212JN United Kingdom

Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

We should have a new release well before the Turkey change, yes. It doesn't seem that urgent, since it's a month from now. But if there's sentiment to push out a version now I can do that.

Given the software release process at many companies, “a month from now” is actually extremely urgent. Thanks, Debbie On Feb 27, 2014, at 11:37 AM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:

On 02/27/2014 07:01 AM, Seán Coffey wrote:

...

Are we expecting an official tzdata release?

We should have a new release well before the Turkey change, yes. It doesn't seem that urgent, since it's a month from now. But if there's sentiment to push out a version now I can do that.

certainly "the sooner the better" seems like a good rule of thumb to me. like the others, i can upgrade to your latest release immediately (and it's all scripted, so any given tzdata release costs me almost nothing[1]), but it can be a long time from then until the update gets into users' hands. in particular, it's non-linear; there are distinct cutoffs where a day's difference on your end can mean several months from the users' perspective. sadly, the last day we can get tzdata changes in is unlikely to be something any of us can tell you :-) the flip side is that if a release contains data you're not sure about, it could be that users have to live with that for months because the bad data made it in and the correction didn't. i don't think there's anything we can do about that though; it's just the nature of the data that it's always going to be a best guess. ____ 1. this will be truer if/when we can wean icu4c off its own copy of the tzdata. but that's our problem, not yours. On Thu, Feb 27, 2014 at 12:02 PM, <Paul_Koning@dell.com> wrote:

On Feb 27, 2014, at 2:55 PM, Deborah Goldsmith <goldsmit@apple.com> wrote:

...

...

We should have a new release well before the Turkey change, yes. It doesn't seem that urgent, since it's a month from now. But if there's sentiment to push out a version now I can do that.

Given the software release process at many companies, “a month from now” is actually extremely urgent.

Actually, given the software release processes some of us have, a month lead time is about an order of magnitude too small. :-(

paul

-- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Java i18n/JNI/NIO, or bionic questions? Mail me/drop by/add me as a reviewer.

Andy Heninger <aheninger@google.com> wrote on Thu, 27 Feb 2014 at 15:32:42 -0800 in <CAFXfk_3HsxkRK1UmEj0_rb5uVN-E-6QWN7HbQcqUUv25t7iEfg@mail.gmail.com>:

When users schedule events, the times are typically stored in a calendar database in UTC/GMT.

This is, of course, the wrong way to go. What *SHOULD* happen is that events should have a home timezone, and they should be stored in that timezone. It may be a different home timezone for different events, and some software may not be so flexible, but that's how it should work. Defaulting to UTC is just wrong -- it'll be more wrong than it is right, and is worse than just using the user's local timezone (and remembering what it is).

The conversion happens when the event is created. If a subsequent tz rule update changes the GMT offset of the (future) event times, the previously scheduled events will appear to move. For events that are shared among people in multiple time zones there is no good answer.

For events shared among multiple people it's not great, but the answer is to pick a timezone for the event, typically the timezone of the lead host, and reference it clearly. --jhawk@mit.edu John Hawkinson

Date: Fri, 28 Feb 2014 04:07:41 +0000 From: David Braverman <david@braverman.org> Message-ID: <f287265160024d36bb98f9709dab9b68@BLUPR04MB037.namprd04.prod.outlook.com> | Record prospective events in wall-clock time, | and retrospective events in UTC, maybe? No, jhawk had it correct, events dealing with times should always have a timezone attached. For many things, it can just be implied (though that can cause weird situations to arise) but for things like scheduling, it should be explicit. This doesn't mean (and I am sure jhawk didn't intend) that UTC can't be the attached timezone when it is appropriate (for international network meetings, it can be, as it means that people in jurisdictions where summer time applies get the meeting time adjusted when summer time turns on/off, and people who don't deal with summer time, get constant times - whereas if a similar meeting is scheduled in local time of someone who has summer time, then some participants get to deal with two variations a few weeks apart, and perhaps a 2 hour meeting time shift - scheduling in local time of an area where summer time doesn't apply is isomorphic to picking UTC of course.) On the other hand, what the default should be is a user interface issue. As long as anything can be selected, I would be less emphatic than jhawk that it should not be UTC - what is best depends entirely upon what is easiest (most common) for most of the users, and the events they are scheduling. There's unlikely to be a single default that is best for everyone - which also implies that there's unlikely to be any singe default that is worst for everything. After all of that, to return to the original point, I certainly agree that it is better to get these kinds of changes published as quickly as possible. On the other hand, I also appreciate the desire to avoid making large numbers of releases in a short period - it is always tempting to wait for the next random govt to make some last minute arbitrary change and bundle the updates together - especially at this time of the year when that kind of thing is (unfortunately) common. Getting the balance between those two correct is hard. kre

David Braverman <david@braverman.org> wrote: |Thoughts? Packed date representation (as in 0x20140228 but better) plus organization-internal shorthand of TZID. |David Braverman |Chicago Steffen, Darmstadt

On 27/02/14 23:32, Andy Heninger wrote:

When users schedule events, the times are typically stored in a calendar database in UTC/GMT. The conversion happens when the event is created. If a subsequent tz rule update changes the GMT offset of the (future) event times, the previously scheduled events will appear to move. For events that are shared among people in multiple time zones there is no good answer.

That doesn't work. I'm in the UK, but I have a weekly meeting scheduled for 11am pacific time. It's always at 11am in California, week in, week out. When the US switches to and from DST it's still at 11am local time. For me, in the UK, it's at 7pm most of the year but for two weeks in Spring it's at 6pm and for a week in Autumn it's also at 6pm. If it were a constant time in UTC then the weekly meeting would be at a different local time for the whole of the summer months, both in the UK and in California. The rule really is "Each Monday at 11am, America/Los_Angeles time". And even should legislation change the definition of America/Los_Angeles, that would still be the case. (Legislation can't change past timezones, not without a time machine.) jch

On 27/02/14 11:37, Paul Eggert wrote:

On 02/27/2014 07:01 AM, Seán Coffey wrote:

...

Are we expecting an official tzdata release?

We should have a new release well before the Turkey change, yes. It doesn't seem that urgent, since it's a month from now. But if there's sentiment to push out a version now I can do that.

Judging from the follow on emails, it seems like a release containing the latest tzdata changes would be welcome. We're under 4 weeks away to the Turkey DST changes. That's probably a good time buffer to allow most companies (but not all) to get software updates out. Could we get 2014a released this week perhaps ? regards, Sean.

...

...

...

...

"Neil" == Neil Masson <NMASSON@uk.ibm.com> writes:

Neil> "The Turkish government has just announced that Daylight Saving Time (DST) Neil> will begin at 3:00 a.m. (03:00) local time on Monday, March 31, 2014, when Neil> clocks will be turned forward one hour to 4:00 a.m. (04:00). This is one Neil> day later than anticipated. Turkey's normal DST schedule is synchronized Neil> with that of most European countries. " Neil> http://www.timeanddate.com/news/time/turkey-starts-dst-2014.html Having landed on a flight from the states to Istanbul (via AMS) on March 31, I can tell you that NOBODY (even the airlines) respected this timezone DST change delay. Maybe the word just didn't get out in time. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix consulting, Technical writing, Comedy, etc. etc. Still trying to think of something clever for the fourth line of this .sig