[tz] Uruguay out of DST

[Chris Erskine]

That is true and there are issues for the cleanup.  The other side is that if you want to go buy a plane ticket today, would you not want the correct departure time on it?

Towards Garrett's comment on batching up changes, I do not need to take every change that comes out.  But if I have long release cycles, it would be nice to have the latest data available at the time I start the cycle.  It may take 3 months to get the data through the system but if I cannot get it until it is just ready to go live, then my 3 month cycle means that you are forcing me to not be current.  There are some folks that have looked at putting this data in a database just so that it can be current.

Each organizations should be able to set their schedule based upon their needs but if the concept is no rush since it is not occurring for several months, you are affecting some folks.

-----Original Message-----
From: Paul_Koning at Dell.com [mailto:Paul_Koning at Dell.com] 
Sent: Thursday, July 09, 2015 11:30 AM
To: Chris Erskine
Cc: tz at iana.org
Subject: Re: [tz] Uruguay out of DST


> On Jul 9, 2015, at 1:17 PM, Chris Erskine <chris at cerskine.com> wrote:
> 
> Actually, there are reasons to put this out as soon as you can.  If I schedule something today that occurs when the change occurs, then my data will be out of sync.  Some organizations will be dependent on future times and need the data update ASAP.  These type of organizations will try to turn around changes quickly.  Other organizations may not care as much so they will not push to get the update.

But that only helps for events you create after the date when the change becomes known.  

Suppose I have a regular meeting “every monday at 10 am, until further notice”.  If the politicians change the TZ rules after the creation time of that repeating appointment, the later occurrences will be wrong.

More precisely, that will be the case if you translate the time to UTC when the appointment is created.  So the answer is that doing so is a bug: you have to save the time as local time of the meeting owner, and not as UTC.  With that fix, the issue you mentioned goes away.

	paul