According to media in Uruguay, it looks like they will not be using DST the coming summer: http://www.elobservador.com.uy/gobierno-resolvio-que-no-habra-cambio-horario... http://www.republica.com.uy/este-ano-no-se-modificara-el-huso-horario-en-uru... It is a bit unclear if this is just this coming summer, or a permanent change. Our English summary (will be updated when we know more details): http://www.timeanddate.com/news/time/uruguay-stops-dst-2015.html Best regards, Steffen Thorsen - timeanddate.com
Looks like it is permanent. The Uruguayan Chamber of Tourism writes (in Spanish) that the decree eliminates DST (not mentioning any specific year). Their main reason is that DST severely harms the tourism sector. Source: http://www.camtur.com.uy/index.php/noticias/281-se-derogo-decreto-del-cambio... Even Scharning http://time.is/ On 2015-07-01 3:09, Paul Eggert wrote:
Steffen Thorsen wrote:
According to media in Uruguay, it looks like they will not be using DST the coming summer:
Thanks for the heads-up. I installed the attached patch into the experimental version on github.
Hi, Is there a plan to release a new version of tz soon with the changes for Uruguay? Thanks, Deborah
On Jul 1, 2015, at 12:09 AM, Even Scharning <tzdb@time.is> wrote:
Looks like it is permanent. The Uruguayan Chamber of Tourism writes (in Spanish) that the decree eliminates DST (not mentioning any specific year). Their main reason is that DST severely harms the tourism sector.
Source: http://www.camtur.com.uy/index.php/noticias/281-se-derogo-decreto-del-cambio...
Even Scharning http://time.is/
On 2015-07-01 3:09, Paul Eggert wrote:
Steffen Thorsen wrote:
According to media in Uruguay, it looks like they will not be using DST the coming summer:
Thanks for the heads-up. I installed the attached patch into the experimental version on github.
On 07/08/2015 10:26 AM, Deborah Goldsmith wrote:
Is there a plan to release a new version of tz soon with the changes for Uruguay?
There's no specific plan, no. I'd be surprised if a new version came out all that soon. The Uruguay change doesn't take effect for three months, so there's no rush for organizations that can turn around tz changes relatively quickly. Conversely, projects that take many months to upgrade will be late no matter what we do. That being said, we shouldn't wait indefinitely for a new version.
Wouldn’t it be best to turn updates around as soon as the information is confirmed? There is a middle ground between “turn around tz changes relatively quickly” and “take many months to upgrade.” In fact, there’s a continuum of turnaround times. The sooner IANA makes a release, the sooner organizations can get the data out there. Is there an advantage to waiting? Thanks, Deborah
On Jul 8, 2015, at 5:46 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 07/08/2015 10:26 AM, Deborah Goldsmith wrote:
Is there a plan to release a new version of tz soon with the changes for Uruguay?
There's no specific plan, no.
I'd be surprised if a new version came out all that soon. The Uruguay change doesn't take effect for three months, so there's no rush for organizations that can turn around tz changes relatively quickly. Conversely, projects that take many months to upgrade will be late no matter what we do.
That being said, we shouldn't wait indefinitely for a new version.
the other flaw in that reasoning is that the nature of releases means there are "cliffs" where a one-week delay in a tzdata release can mean missing an OS release, which turns into a 6-month/one-year/eternal delay for users. in practice it's a lot more quantized than a continuum :-) On Thu, Jul 9, 2015 at 10:08 AM, Deborah Goldsmith <goldsmit@apple.com> wrote:
Wouldn’t it be best to turn updates around as soon as the information is confirmed? There is a middle ground between “turn around tz changes relatively quickly” and “take many months to upgrade.” In fact, there’s a continuum of turnaround times. The sooner IANA makes a release, the sooner organizations can get the data out there.
Is there an advantage to waiting?
Thanks, Deborah
On Jul 8, 2015, at 5:46 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 07/08/2015 10:26 AM, Deborah Goldsmith wrote:
Is there a plan to release a new version of tz soon with the changes for Uruguay?
There's no specific plan, no.
I'd be surprised if a new version came out all that soon. The Uruguay change doesn't take effect for three months, so there's no rush for organizations that can turn around tz changes relatively quickly. Conversely, projects that take many months to upgrade will be late no matter what we do.
That being said, we shouldn't wait indefinitely for a new version.
-- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer.
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. Chris -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Deborah Goldsmith Sent: Thursday, July 09, 2015 11:08 AM To: Paul Eggert Cc: Time Zone Database Subject: Re: [tz] Uruguay out of DST Wouldn’t it be best to turn updates around as soon as the information is confirmed? There is a middle ground between “turn around tz changes relatively quickly” and “take many months to upgrade.” In fact, there’s a continuum of turnaround times. The sooner IANA makes a release, the sooner organizations can get the data out there. Is there an advantage to waiting? Thanks, Deborah
On Jul 8, 2015, at 5:46 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 07/08/2015 10:26 AM, Deborah Goldsmith wrote:
Is there a plan to release a new version of tz soon with the changes for Uruguay?
There's no specific plan, no.
I'd be surprised if a new version came out all that soon. The Uruguay change doesn't take effect for three months, so there's no rush for organizations that can turn around tz changes relatively quickly. Conversely, projects that take many months to upgrade will be late no matter what we do.
That being said, we shouldn't wait indefinitely for a new version.
<<On Thu, 9 Jul 2015 17:17:15 +0000, Chris Erskine <chris@cerskine.com> said:
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.
Of course, those organizations aren't stuck with just released versions of tzdata, either. The countervailing argument is that, for people who are distributing content derived from tzdata, it would be helpful to batch up changes so that they need not run through their release/QA cycles multiple times for changes that will affect only a small number of customers. -GAWollman
On Jul 9, 2015, at 1:17 PM, Chris Erskine <chris@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
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@Dell.com [mailto:Paul_Koning@Dell.com] Sent: Thursday, July 09, 2015 11:30 AM To: Chris Erskine Cc: tz@iana.org Subject: Re: [tz] Uruguay out of DST
On Jul 9, 2015, at 1:17 PM, Chris Erskine <chris@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
On 07/09/2015 10:08 AM, Deborah Goldsmith wrote:
Is there an advantage to waiting? Yes. After we make a change, sometimes we find that the supplied information was wrong. Sometimes the authorities change their minds. Sometimes we have the correct information but enter the data incorrectly, and don't discover this until further review. In cases like these, dallying before an official release can save us all some work. This is partly why we delayed from March 10 to March 21 before releasing 2015b as an official fix for Mongolia.
If these delays cause problems for you, it's reasonable to use the unofficial repository at <https://github.com/eggert/tz> as a basis for operating system patches. That is, users of the tz database have a choice of either a bleeding edge unofficial version that is more up-to-date but is also more likely to contain errors, or a more-stable official version that may not have the very latest experimental changes but should work well for those who keep reasonably up-to-date with the official version.
It’s certainly appropriate to verify the data is correct before releasing it. I was responding to the idea that there’s no rush to release it. It’s important for many companies for IANA to release the data as soon as possible, so there is time to integrate it. As someone else pointed out, delays can cause new data to miss a release and have to wait for the next one. That can make the difference between being in time for a change, and not being in time. Let me rephrase: is there any reason to wait once the data is verified? Is there anything we can do to increase confidence in this particular change? Thanks, Deborah
On Jul 10, 2015, at 12:05 AM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 07/09/2015 10:08 AM, Deborah Goldsmith wrote:
Is there an advantage to waiting? Yes. After we make a change, sometimes we find that the supplied information was wrong. Sometimes the authorities change their minds. Sometimes we have the correct information but enter the data incorrectly, and don't discover this until further review. In cases like these, dallying before an official release can save us all some work. This is partly why we delayed from March 10 to March 21 before releasing 2015b as an official fix for Mongolia.
If these delays cause problems for you, it's reasonable to use the unofficial repository at <https://github.com/eggert/tz> as a basis for operating system patches. That is, users of the tz database have a choice of either a bleeding edge unofficial version that is more up-to-date but is also more likely to contain errors, or a more-stable official version that may not have the very latest experimental changes but should work well for those who keep reasonably up-to-date with the official version.
On 07/10/2015 09:15 AM, Deborah Goldsmith wrote:
is there any reason to wait once the data is verified?
"Verified" is not Boolean. Have we verified the upcoming Uruguay change? Not really, not nearly as much as (say) we verified the most-recent US change -- and even if we had better confirmation, the Uruguayan change is controversial and perhaps they'll change their minds. Have we verified the upcoming Moldova change? More than Uruguay, but even there the start date for that change is sheer guesswork on my part. So it's quite possible that the proposed Moldovan and Uruguayan changes are wrong, at least in part. Also, there's overhead to making a release. Even when data can be 99.999% verified there is still benefit to having ten releases a year instead of fifty, if ten will do. Downstream users of the tz database need to be reasonably prompt in applying new releases anyway. Governments sometimes decide changes only a few days before they take effect, so if users care about timestamps, OS release schedules simply cannot require three-month delays. This is true regardless of whether we issue a new Uruguayan-related tz release this week or next week.
On Fri 2015-07-10T10:24:49 -0700, Paul Eggert hath writ:
Also, there's overhead to making a release. Even when data can be 99.999% verified there is still benefit to having ten releases a year instead of fifty, if ten will do.
Downstream users of the tz database need to be reasonably prompt in applying new releases anyway. Governments sometimes decide changes only a few days before they take effect, so if users care about timestamps, OS release schedules simply cannot require three-month delays. This is true regardless of whether we issue a new Uruguayan-related tz release this week or next week.
I think we should expect that these economics and timing of timezone information authority, packaging, and distribution will change if the Time Zone Data Distribution Service (tzdist) becomes a widely implemented standard. https://datatracker.ietf.org/wg/tzdist/documents/ Changing the distribution of the information from OS updates to on-demand web service may mean that the IANA efforts of this mail list, Apple, Microsoft, Google, etc. will all have to decide how they want to fit into that new model of "publishers" and "providers". This current discussion about Uruguay seems to be leading toward that process. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
I do now that several years ago Oracle did not release a Java update that included the TZdata updates for a change in Timezone information until 72 hours after the change went into affect. Large companies like Oracle, Microsoft, etc. move as fast a Governments. Cheers, -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Steve Allen Sent: Friday, July 10, 2015 1:39 PM To: Time Zone Database discussion Subject: [EXT] Re: [tz] Uruguay out of DST On Fri 2015-07-10T10:24:49 -0700, Paul Eggert hath writ:
Also, there's overhead to making a release. Even when data can be 99.999% verified there is still benefit to having ten releases a year instead of fifty, if ten will do.
Downstream users of the tz database need to be reasonably prompt in applying new releases anyway. Governments sometimes decide changes only a few days before they take effect, so if users care about timestamps, OS release schedules simply cannot require three-month delays. This is true regardless of whether we issue a new Uruguayan-related tz release this week or next week.
I think we should expect that these economics and timing of timezone information authority, packaging, and distribution will change if the Time Zone Data Distribution Service (tzdist) becomes a widely implemented standard. https://datatracker.ietf.org/wg/tzdist/documents/ Changing the distribution of the information from OS updates to on-demand web service may mean that the IANA efforts of this mail list, Apple, Microsoft, Google, etc. will all have to decide how they want to fit into that new model of "publishers" and "providers". This current discussion about Uruguay seems to be leading toward that process. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
Large client corps/orgs with a few thousand each Linux, MS, Oracle servers are not a lot faster. Dynamic online tz updates are as desirable for their stability impact as Windows updates ;^> Dynamic online updates are really intended to allow personal clients to accept a certain downside risk and not have to think about updates. Most IT people and groups prefer stability, and while they may automatically download updates, will test and evaluate the risk before applying. Don't see a web source delta distro solving any problems or adding much value, unless vendors see enough downstream support savings to build the download and update process for the binary data, which they have not done yet. Someone may decide to build an app for that. -- Take care. Thanks, Brian Inglis On 2015-07-14 05:32, Rich Gombert wrote:
I do now that several years ago Oracle did not release a Java update that included the TZdata updates for a change in Timezone information until 72 hours after the change went into affect. Large companies like Oracle, Microsoft, etc. move as fast a Governments.
-----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Steve Allen Sent: Friday, July 10, 2015 1:39 PM To: Time Zone Database discussion Subject: [EXT] Re: [tz] Uruguay out of DST
On Fri 2015-07-10T10:24:49 -0700, Paul Eggert hath writ:
Also, there's overhead to making a release. Even when data can be 99.999% verified there is still benefit to having ten releases a year instead of fifty, if ten will do.
Downstream users of the tz database need to be reasonably prompt in applying new releases anyway. Governments sometimes decide changes only a few days before they take effect, so if users care about timestamps, OS release schedules simply cannot require three-month delays. This is true regardless of whether we issue a new Uruguayan-related tz release this week or next week.
I think we should expect that these economics and timing of timezone information authority, packaging, and distribution will change if the Time Zone Data Distribution Service (tzdist) becomes a widely implemented standard. https://datatracker.ietf.org/wg/tzdist/documents/ Changing the distribution of the information from OS updates to on-demand web service may mean that the IANA efforts of this mail list, Apple, Microsoft, Google, etc. will all have to decide how they want to fit into that new model of "publishers" and "providers". This current discussion about Uruguay seems to be leading toward that process.
Brian Inglis wrote:
Large client corps/orgs with a few thousand each Linux, MS, Oracle servers are not a lot faster. Dynamic online tz updates are as desirable for their stability impact as Windows updates ;^>
Dynamic online updates are really intended to allow personal clients to accept a certain downside risk and not have to think about updates. Most IT people and groups prefer stability, and while they may automatically download updates, will test and evaluate the risk before applying. Don't see a web source delta distro solving any problems or adding much value, unless vendors see enough downstream support savings to build the download and update process for the binary data, which they have not done yet. Someone may decide to build an app for that.
I think large companies don't have to evaluate updates e.g of the TZ data for every single client device. However, I'd expect that they can set up their own company tzdist server, just like they have their company NTP servers today, so the company admin just has to take care about their own tzdist server, and keep it up to date, and all devices in the company can pull the TZ updates from their own local server. So this eliminates the dependency from external servers, but also significantly reduces the effort to update each device manually. Martin
On 2015-07-14 13:36, Martin Burnicki wrote:
Brian Inglis wrote:
Large client corps/orgs with a few thousand each Linux, MS, Oracle servers are not a lot faster. Dynamic online tz updates are as desirable for their stability impact as Windows updates ;^>
Dynamic online updates are really intended to allow personal clients to accept a certain downside risk and not have to think about updates. Most IT people and groups prefer stability, and while they may automatically download updates, will test and evaluate the risk before applying. Don't see a web source delta distro solving any problems or adding much value, unless vendors see enough downstream support savings to build the download and update process for the binary data, which they have not done yet. Someone may decide to build an app for that.
I think large companies don't have to evaluate updates e.g of the TZ data for every single client device.
However, I'd expect that they can set up their own company tzdist server, just like they have their company NTP servers today, so the company admin just has to take care about their own tzdist server, and keep it up to date, and all devices in the company can pull the TZ updates from their own local server.
So this eliminates the dependency from external servers, but also significantly reduces the effort to update each device manually.
TZdist seems to require a server which tracks changes at zone and impacted date time range levels (implying also dependencies on rules and aliases). The server would have to pull apart the current zoneinfo source or binary files and track when changes happened and what ranges were impacted. The server returns zone info within changed and impacted date time ranges of interest to the client in iCalendar, XML, or JSON formats, where the client then has to decide how to apply these to its data base. This would allow automated updating for calendar applications but not obviously for system zoneinfo data, which is the topic of interest, and would require an iCalendar parser hooked up to part of the zic compiler. Seems to provide many extra opportunities for Murphy. -- Take care. Thanks, Brian Inglis
On Jul 14, 2015, at 4:56 PM, Brian Inglis <Brian.Inglis@SystematicSW.ab.ca> wrote:
...
TZdist seems to require a server which tracks changes at zone and impacted date time range levels (implying also dependencies on rules and aliases). The server would have to pull apart the current zoneinfo source or binary files and track when changes happened and what ranges were impacted. The server returns zone info within changed and impacted date time ranges of interest to the client in iCalendar, XML, or JSON formats, where the client then has to decide how to apply these to its data base.
This would allow automated updating for calendar applications but not obviously for system zoneinfo data, which is the topic of interest, and would require an iCalendar parser hooked up to part of the zic compiler.
I don’t understand why you make those assumptions. tzdist is just a protocol for conveying timezone data. It’s clearly possible to feed that data into the “system zoneinfo data”, that’s purely a local matter. paul
On 2015-07-15 08:54, Paul_Koning@Dell.com wrote:
On Jul 14, 2015, at 4:56 PM, Brian Inglis <Brian.Inglis@SystematicSW.ab.ca> wrote:
...
TZdist seems to require a server which tracks changes at zone and impacted date time range levels (implying also dependencies on rules and aliases). The server would have to pull apart the current zoneinfo source or binary files and track when changes happened and what ranges were impacted. The server returns zone info within changed and impacted date time ranges of interest to the client in iCalendar, XML, or JSON formats, where the client then has to decide how to apply these to its data base.
This would allow automated updating for calendar applications but not obviously for system zoneinfo data, which is the topic of interest, and would require an iCalendar parser hooked up to part of the zic compiler.
I don’t understand why you make those assumptions. tzdist is just a protocol for conveying timezone data. It’s clearly possible to feed that data into the “system zoneinfo data”, that’s purely a local matter.
Aren't protocols developed based on "rough consensus and running code"? That normally requires demonstrating protocol interoperability between a couple each of sources and sinks. Where are the demo servers and clients available? -- Take care. Thanks, Brian Inglis
On Jul 15, 2015, at 11:37 PM, Brian Inglis <Brian.Inglis@SystematicSW.ab.ca> wrote:
On 2015-07-15 08:54, Paul_Koning@Dell.com wrote:
On Jul 14, 2015, at 4:56 PM, Brian Inglis <Brian.Inglis@SystematicSW.ab.ca> wrote:
...
TZdist seems to require a server which tracks changes at zone and impacted date time range levels (implying also dependencies on rules and aliases). The server would have to pull apart the current zoneinfo source or binary files and track when changes happened and what ranges were impacted. The server returns zone info within changed and impacted date time ranges of interest to the client in iCalendar, XML, or JSON formats, where the client then has to decide how to apply these to its data base.
This would allow automated updating for calendar applications but not obviously for system zoneinfo data, which is the topic of interest, and would require an iCalendar parser hooked up to part of the zic compiler.
I don’t understand why you make those assumptions. tzdist is just a protocol for conveying timezone data. It’s clearly possible to feed that data into the “system zoneinfo data”, that’s purely a local matter.
Aren't protocols developed based on "rough consensus and running code"? That normally requires demonstrating protocol interoperability between a couple each of sources and sinks. Where are the demo servers and clients available?
“rough consensus and running code” applies once you get far enough along. In particular it is required to get a protocol approved for its second and subsequent stages of standardization. But while rough consensus is required, you don’t require running code, or demonstrated interoperability, just to get the original spec out the door. Currently there is a draft protocol spec. People can start implementing from that (and I assume they are doing exactly that). A client prototype can talk to a server prototype and do something useful with the data it gets. One thing it could do, if it wants to, is generate system zoneinfo files from what it learns. Or it can do something entirely different. What I meant is: the spec says how client and server communicate; it does not say or constrain what the client does with the data it receives. You said it would “not obviously [allow updating] for system zoneinfo data, which is the topic of interest”. I agree that it’s of significant interest; I do not agree that there is any difficulty in updating zoneinfo data. Not unless the draft protocol omits necessary information, in which case that’s a protocol bug that can easily be fixed once identified. paul
“Verified" is not Boolean.
Of course it isn’t; that’s not what I was trying to say. If you want to substitute “reasonably confident of,” that’s fine. I understand there is a tradeoff between timeliness and confidence.
Downstream users of the tz database need to be reasonably prompt in applying new releases anyway. Governments sometimes decide changes only a few days before they take effect, so if users care about timestamps, OS release schedules simply cannot require three-month delays. This is true regardless of whether we issue a new Uruguayan-related tz release this week or next week.
As I’m sure you’re aware, considerations of time zone updates are not the only factor in determining OS release schedules. It’s unfortunately a fact of life that the further in advance an update is available, the more likely it is to be released in a timely fashion. I would love to be able to turn a tz release around in a week. That is not currently possible. Based on comments by others on this list, I suspect it’s not possible for them, either. I will investigate the option of proceeding based on the git repository, but of course an official release from IANA is much preferred. Thanks, Deborah
On Jul 10, 2015, at 10:24 AM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 07/10/2015 09:15 AM, Deborah Goldsmith wrote:
is there any reason to wait once the data is verified?
"Verified" is not Boolean. Have we verified the upcoming Uruguay change? Not really, not nearly as much as (say) we verified the most-recent US change -- and even if we had better confirmation, the Uruguayan change is controversial and perhaps they'll change their minds. Have we verified the upcoming Moldova change? More than Uruguay, but even there the start date for that change is sheer guesswork on my part. So it's quite possible that the proposed Moldovan and Uruguayan changes are wrong, at least in part.
Also, there's overhead to making a release. Even when data can be 99.999% verified there is still benefit to having ten releases a year instead of fifty, if ten will do.
Downstream users of the tz database need to be reasonably prompt in applying new releases anyway. Governments sometimes decide changes only a few days before they take effect, so if users care about timestamps, OS release schedules simply cannot require three-month delays. This is true regardless of whether we issue a new Uruguayan-related tz release this week or next week.
On 07/10/2015 12:30 PM, Deborah Goldsmith wrote:
I would love to be able to turn a tz release around in a week. That is not currently possible.
It is currently possible to do it in far less time than a week, for other operating systems. For example, the 2014c release was turned around in about two hours by Debian, and in about three hours by Ubuntu; see <http://mm.icann.org/pipermail/tz/2014-May/020907.html>. This wasn't a complete new OS release: it was merely a patch, but that's good enough to solve the problem. Two hours is pretty fast, and we can't expect redistributors to be that fast every time; even Debian doesn't do that. But it should be eminently doable to release an automatically-installable patch within a week. A three-month delay is waaayyy too long.
On Fri, Jul 10, 2015 at 11:52 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 07/10/2015 12:30 PM, Deborah Goldsmith wrote:
I would love to be able to turn a tz release around in a week. That is not currently possible.
It is currently possible to do it in far less time than a week, for other operating systems. For example, the 2014c release was turned around in about two hours by Debian, and in about three hours by Ubuntu; see <http://mm.icann.org/pipermail/tz/2014-May/020907.html>. This wasn't a complete new OS release: it was merely a patch, but that's good enough to solve the problem.
Two hours is pretty fast, and we can't expect redistributors to be that fast every time; even Debian doesn't do that. But it should be eminently doable to release an automatically-installable patch within a week. A three-month delay is waaayyy too long.
it is, unfortunately, the world we live in. -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer.
On Jul 10, 2015, at 11:54 PM, enh <enh@google.com> wrote:
it is, unfortunately, the world we live in.
Who's "we", why does "our" operating system not allow the tz database files to be updated without doing a complete new OS release or something as heavyweight as that, and how do we fix that?
On Sat, Jul 11, 2015 at 12:11 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Jul 10, 2015, at 11:54 PM, enh <enh@google.com> wrote:
it is, unfortunately, the world we live in.
Who's "we",
between Android and iOS, the majority of people with computing devices.
why does "our" operating system not allow the tz database files to be updated without doing a complete new OS release or something as heavyweight as that, and how do we fix that?
how things look in the future is a separate discussion. we're talking about the practicalities of getting tzdata into users' hands _today_. -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer.
On Jul 11, 2015, at 9:34 AM, enh <enh@google.com> wrote:
On Sat, Jul 11, 2015 at 12:11 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Jul 10, 2015, at 11:54 PM, enh <enh@google.com> wrote:
it is, unfortunately, the world we live in.
Who's "we",
between Android and iOS, the majority of people with computing devices.
why does "our" operating system not allow the tz database files to be updated without doing a complete new OS release or something as heavyweight as that, and how do we fix that?
how things look in the future is a separate discussion. we're talking about the practicalities of getting tzdata into users' hands _today_.
So what's the time frame difference between "today" and "the future"? I.e., how soon can various vendors - including *but not limited to* Apple and Google, given that there are also a number of significant computing devices out there that run neither Android nor iOS (and without which a lot of those Android and iOS machines won't be able to get very much interesting stuff from the Interwebs) - deploy mechanisms to update time zone files without having to spin an entire OS release just to note that Elbonia is changing to start using DST? "Mechanisms" here includes both "a way by which an update can be pushed to machines, preferably without requiring a reboot" and "a way by which the vendor's process can treat a time zone data update as being more lightweight than a full OS release". As per my earlier mail, Apple, at least, have demonstrated that they can distribute other less-than-a-full-OS release update. So, whilst we probably shouldn't delay the Uruguay update *too* much, ultimately this needs some effort on the part of distributors. The governments of the world, sadly, don't pay much attention to vendor release schedules when making changes to their DST rules, so, sadly, there *will* be times when a necessary time zone database won't line up nicely with an OS update.
On Sat, Jul 11, 2015 at 11:16 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Jul 11, 2015, at 9:34 AM, enh <enh@google.com> wrote:
On Sat, Jul 11, 2015 at 12:11 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Jul 10, 2015, at 11:54 PM, enh <enh@google.com> wrote:
it is, unfortunately, the world we live in.
Who's "we",
between Android and iOS, the majority of people with computing devices.
why does "our" operating system not allow the tz database files to be updated without doing a complete new OS release or something as heavyweight as that, and how do we fix that?
how things look in the future is a separate discussion. we're talking about the practicalities of getting tzdata into users' hands _today_.
So what's the time frame difference between "today" and "the future"?
I.e., how soon can various vendors - including *but not limited to* Apple and Google, given that there are also a number of significant computing devices out there that run neither Android nor iOS (and without which a lot of those Android and iOS machines won't be able to get very much interesting stuff from the Interwebs) - deploy mechanisms to update time zone files without having to spin an entire OS release just to note that Elbonia is changing to start using DST?
"Mechanisms" here includes both "a way by which an update can be pushed to machines, preferably without requiring a reboot" and "a way by which the vendor's process can treat a time zone data update as being more lightweight than a full OS release". As per my earlier mail, Apple, at least, have demonstrated that they can distribute other less-than-a-full-OS release update.
So, whilst we probably shouldn't delay the Uruguay update *too* much, ultimately this needs some effort on the part of distributors. The governments of the world, sadly, don't pay much attention to vendor release schedules when making changes to their DST rules, so, sadly, there *will* be times when a necessary time zone database won't line up nicely with an OS update.
no one is arguing otherwise. but in the meantime, the less time spent sitting on updates without a good reason to delay, the worse for everyone. -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer.
I find it hard to believe that anything as a full OS update is required to update time zone data, but even if so, not to be callous or anything, but this only affects people in areas where time zones are unstable on short notice. This is probably a fairly small number of people in the scheme of things, and it's not like the inconvenience would persist indefinitely. The fact that the unstable version is updated almost immediately seems to be a decent mitigation strategy for critical applications, but I'm perfectly fine deferring to Paul's judgment on this rather than jumping through hoops to accommodate crazy time zone authorities who change things like this on very little notice. On Jul 11, 2015 2:35 PM, "enh" <enh@google.com> wrote:
On Sat, Jul 11, 2015 at 11:16 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Jul 11, 2015, at 9:34 AM, enh <enh@google.com> wrote:
On Sat, Jul 11, 2015 at 12:11 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Jul 10, 2015, at 11:54 PM, enh <enh@google.com> wrote:
it is, unfortunately, the world we live in.
Who's "we",
between Android and iOS, the majority of people with computing devices.
why does "our" operating system not allow the tz database files to be
updated without doing a complete new OS release or something as heavyweight as that, and how do we fix that?
how things look in the future is a separate discussion. we're talking about the practicalities of getting tzdata into users' hands _today_.
So what's the time frame difference between "today" and "the future"?
I.e., how soon can various vendors - including *but not limited to* Apple and Google, given that there are also a number of significant computing devices out there that run neither Android nor iOS (and without which a lot of those Android and iOS machines won't be able to get very much interesting stuff from the Interwebs) - deploy mechanisms to update time zone files without having to spin an entire OS release just to note that Elbonia is changing to start using DST?
"Mechanisms" here includes both "a way by which an update can be pushed to machines, preferably without requiring a reboot" and "a way by which the vendor's process can treat a time zone data update as being more lightweight than a full OS release". As per my earlier mail, Apple, at least, have demonstrated that they can distribute other less-than-a-full-OS release update.
So, whilst we probably shouldn't delay the Uruguay update *too* much, ultimately this needs some effort on the part of distributors. The governments of the world, sadly, don't pay much attention to vendor release schedules when making changes to their DST rules, so, sadly, there *will* be times when a necessary time zone database won't line up nicely with an OS update.
no one is arguing otherwise. but in the meantime, the less time spent sitting on updates without a good reason to delay, the worse for everyone.
-- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer.
On 11/07/15 20:54, Paul Ganssle wrote:
I find it hard to believe that anything as a full OS update is required to update time zone data, but even if so, not to be callous or anything, but this only affects people in areas where time zones are unstable on short notice. This is probably a fairly small number of people in the scheme of things, and it's not like the inconvenience would persist indefinitely.
Actually that was one of the arguments for leaving things out of the first pass of the tzdist protocol ... FORTUNATELY it did not get accepted, but some elements of the protocol are 'optional', so a publisher can set up and ignore anything that they can't be bothered to handle! It will still be compliant ... -- 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
... but even if so, not to be callous or anything, but this only affects people in areas where time zones are unstable on short notice.
That's not necessarily true. It also affects anyone that interacts with that time zone. For example, I may be in the United States, but scheduling an online meeting or a phone call with someone in Uruguay. If only the person in Uruguay has the updated time zone information, I might contact them at the wrong time. TZ updates for any zone should be distributed as widely as possible. Not just to those in that particular zone. From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Paul Ganssle Sent: Saturday, July 11, 2015 12:55 PM Cc: tz@iana.org List Subject: Re: [tz] Uruguay out of DST I find it hard to believe that anything as a full OS update is required to update time zone data, but even if so, not to be callous or anything, but this only affects people in areas where time zones are unstable on short notice. This is probably a fairly small number of people in the scheme of things, and it's not like the inconvenience would persist indefinitely. The fact that the unstable version is updated almost immediately seems to be a decent mitigation strategy for critical applications, but I'm perfectly fine deferring to Paul's judgment on this rather than jumping through hoops to accommodate crazy time zone authorities who change things like this on very little notice. On Jul 11, 2015 2:35 PM, "enh" <enh@google.com <mailto:enh@google.com> > wrote: On Sat, Jul 11, 2015 at 11:16 AM, Guy Harris <guy@alum.mit.edu <mailto:guy@alum.mit.edu> > wrote:
On Jul 11, 2015, at 9:34 AM, enh <enh@google.com <mailto:enh@google.com> > wrote:
On Sat, Jul 11, 2015 at 12:11 AM, Guy Harris <guy@alum.mit.edu <mailto:guy@alum.mit.edu> > wrote:
On Jul 10, 2015, at 11:54 PM, enh <enh@google.com <mailto:enh@google.com> > wrote:
it is, unfortunately, the world we live in.
Who's "we",
between Android and iOS, the majority of people with computing devices.
why does "our" operating system not allow the tz database files to be updated without doing a complete new OS release or something as heavyweight as that, and how do we fix that?
how things look in the future is a separate discussion. we're talking about the practicalities of getting tzdata into users' hands _today_.
So what's the time frame difference between "today" and "the future"?
I.e., how soon can various vendors - including *but not limited to* Apple and Google, given that there are also a number of significant computing devices out there that run neither Android nor iOS (and without which a lot of those Android and iOS machines won't be able to get very much interesting stuff from the Interwebs) - deploy mechanisms to update time zone files without having to spin an entire OS release just to note that Elbonia is changing to start using DST?
"Mechanisms" here includes both "a way by which an update can be pushed to machines, preferably without requiring a reboot" and "a way by which the vendor's process can treat a time zone data update as being more lightweight than a full OS release". As per my earlier mail, Apple, at least, have demonstrated that they can distribute other less-than-a-full-OS release update.
So, whilst we probably shouldn't delay the Uruguay update *too* much, ultimately this needs some effort on the part of distributors. The governments of the world, sadly, don't pay much attention to vendor release schedules when making changes to their DST rules, so, sadly, there *will* be times when a necessary time zone database won't line up nicely with an OS update.
no one is arguing otherwise. but in the meantime, the less time spent sitting on updates without a good reason to delay, the worse for everyone. -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer.
Certainly a good point, consider my statement appropriately appended. Still, it's probably worth perspective here. It's Uruguay, not China, and Paul is talking about waiting a bit longer to release the unstable version, not delaying indefinitely. Either way there could be inconveniences, and I don't think the magnitude of the inconveniences would be particularly high, on a global scale on either side. Still, I have no stake in the game, really - I haven't felt much pressure to be on the bleeding edge of the time zone releases in the things I work on, so I probably shouldn't have chimed in in the first place. On Jul 12, 2015 5:00 PM, "Matt Johnson" <mj1856@hotmail.com> wrote:
*... but even if so, not to be callous or anything, but this only affects people in areas where time zones are unstable on short notice.*
That's not necessarily true. It also affects anyone that *interacts* with that time zone. For example, I may be in the United States, but scheduling an online meeting or a phone call with someone in Uruguay. If only the person in Uruguay has the updated time zone information, I might contact them at the wrong time.
TZ updates for* any zone* should be distributed as widely as possible. Not just to those in that particular zone.
*From:* tz-bounces@iana.org [mailto:tz-bounces@iana.org] *On Behalf Of *Paul Ganssle *Sent:* Saturday, July 11, 2015 12:55 PM *Cc:* tz@iana.org List *Subject:* Re: [tz] Uruguay out of DST
I find it hard to believe that anything as a full OS update is required to update time zone data, but even if so, not to be callous or anything, but this only affects people in areas where time zones are unstable on short notice. This is probably a fairly small number of people in the scheme of things, and it's not like the inconvenience would persist indefinitely.
The fact that the unstable version is updated almost immediately seems to be a decent mitigation strategy for critical applications, but I'm perfectly fine deferring to Paul's judgment on this rather than jumping through hoops to accommodate crazy time zone authorities who change things like this on very little notice.
On Jul 11, 2015 2:35 PM, "enh" <enh@google.com> wrote:
On Sat, Jul 11, 2015 at 11:16 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Jul 11, 2015, at 9:34 AM, enh <enh@google.com> wrote:
On Sat, Jul 11, 2015 at 12:11 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Jul 10, 2015, at 11:54 PM, enh <enh@google.com> wrote:
it is, unfortunately, the world we live in.
Who's "we",
between Android and iOS, the majority of people with computing devices.
why does "our" operating system not allow the tz database files to be
updated without doing a complete new OS release or something as heavyweight as that, and how do we fix that?
how things look in the future is a separate discussion. we're talking about the practicalities of getting tzdata into users' hands _today_.
So what's the time frame difference between "today" and "the future"?
I.e., how soon can various vendors - including *but not limited to* Apple and Google, given that there are also a number of significant computing devices out there that run neither Android nor iOS (and without which a lot of those Android and iOS machines won't be able to get very much interesting stuff from the Interwebs) - deploy mechanisms to update time zone files without having to spin an entire OS release just to note that Elbonia is changing to start using DST?
"Mechanisms" here includes both "a way by which an update can be pushed to machines, preferably without requiring a reboot" and "a way by which the vendor's process can treat a time zone data update as being more lightweight than a full OS release". As per my earlier mail, Apple, at least, have demonstrated that they can distribute other less-than-a-full-OS release update.
So, whilst we probably shouldn't delay the Uruguay update *too* much, ultimately this needs some effort on the part of distributors. The governments of the world, sadly, don't pay much attention to vendor release schedules when making changes to their DST rules, so, sadly, there *will* be times when a necessary time zone database won't line up nicely with an OS update.
no one is arguing otherwise. but in the meantime, the less time spent sitting on updates without a good reason to delay, the worse for everyone.
-- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer.
I.e., how soon can various vendors - including *but not limited to* Apple and Google, given that there are also a number of significant computing devices out there that run neither Android nor iOS (and without which a lot of those Android and iOS machines won't be able to get very much interesting stuff from the Interwebs) - deploy mechanisms to update time zone files without having to spin an entire OS release just to note that Elbonia is changing to start using DST?
As with all engineering efforts in corporations, as soon as possible, but no sooner. I should also point out that when you’re shipping something to hundreds of millions of customers, more testing is advisable than is possible in two hours. Meanwhile, the current situation is what it is, and we need to get tz updates to customers as quickly as we can. I wouldn’t want to see IANA rush data out before it’s vetted, or if further revisions seem likely, but neither do I want to see IANA sit on the data if it’s unlikely to change. IANA should not be making assumptions about how much time users of the tz database “ought to” need to get it to their customers. Deborah
On Jul 11, 2015, at 11:16 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Jul 11, 2015, at 9:34 AM, enh <enh@google.com> wrote:
On Sat, Jul 11, 2015 at 12:11 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Jul 10, 2015, at 11:54 PM, enh <enh@google.com> wrote:
it is, unfortunately, the world we live in.
Who's "we",
between Android and iOS, the majority of people with computing devices.
why does "our" operating system not allow the tz database files to be updated without doing a complete new OS release or something as heavyweight as that, and how do we fix that?
how things look in the future is a separate discussion. we're talking about the practicalities of getting tzdata into users' hands _today_.
So what's the time frame difference between "today" and "the future"?
I.e., how soon can various vendors - including *but not limited to* Apple and Google, given that there are also a number of significant computing devices out there that run neither Android nor iOS (and without which a lot of those Android and iOS machines won't be able to get very much interesting stuff from the Interwebs) - deploy mechanisms to update time zone files without having to spin an entire OS release just to note that Elbonia is changing to start using DST?
"Mechanisms" here includes both "a way by which an update can be pushed to machines, preferably without requiring a reboot" and "a way by which the vendor's process can treat a time zone data update as being more lightweight than a full OS release". As per my earlier mail, Apple, at least, have demonstrated that they can distribute other less-than-a-full-OS release update.
So, whilst we probably shouldn't delay the Uruguay update *too* much, ultimately this needs some effort on the part of distributors. The governments of the world, sadly, don't pay much attention to vendor release schedules when making changes to their DST rules, so, sadly, there *will* be times when a necessary time zone database won't line up nicely with an OS update.
On Jul 11, 2015, at 12:42 PM, Deborah Goldsmith <goldsmit@apple.com> wrote:
I.e., how soon can various vendors - including *but not limited to* Apple and Google, given that there are also a number of significant computing devices out there that run neither Android nor iOS (and without which a lot of those Android and iOS machines won't be able to get very much interesting stuff from the Interwebs) - deploy mechanisms to update time zone files without having to spin an entire OS release just to note that Elbonia is changing to start using DST?
As with all engineering efforts in corporations, as soon as possible, but no sooner.
So, if it hasn't already been suggested, could you suggest that Apple provide tzdb updates in the same fashion in which they provide printer driver updates and RAW camera updates, so that tzdb updates do *not* have to correspond to OS updates? And perhaps do something even *more* automatic for iOS/AppleTVOS/WatchOS? (Heck, I think the malware database updates happen automatically even for OS X, so maybe tzdb updates should happen automatically as well.)
I should also point out that when you’re shipping something to hundreds of millions of customers, more testing is advisable than is possible in two hours.
I'm aware of that; how much testing time *is* reasonable? (Note that the time scale is up to governments as much as it's up to the tzdb maintainers, if not more so; an announcement from the Elbonian government that they're permanently going off DST this weekend may not leave much time for testing.)
Meanwhile, the current situation is what it is, and we need to get tz updates to customers as quickly as we can. I wouldn’t want to see IANA rush data out before it’s vetted, or if further revisions seem likely, but neither do I want to see IANA sit on the data if it’s unlikely to change.
"Unlikely to change" can be hard to guess. My inclination is to assume no upper bound on the perversity of governments in, at least, announcing arbitrary changes, including changing their mind several times.
I think Deb Goldsmith is right and the tz db needs to change its release dynamics, which could happen in a few ways. But it could also improve the documentation of the release dynamics. I think we should hope that tzdist can get deployed before major vendors find a "magic bullet" to speed up their OS releases. As such, it's not compelling at this juncture (with tzdist around the corner?) to ask vendors to do that -- even if it were possible, which I think it really isn't. Paul Eggert <eggert@cs.ucla.edu> wrote on Fri, 10 Jul 2015 at 00:05:57 -0700 in <559F6ED5.6040701@cs.ucla.edu>:
If these delays cause problems for you, it's reasonable to use the unofficial repository at <https://github.com/eggert/tz> as a basis for operating system patches. That is, users of the tz database have a choice of either a bleeding edge unofficial version that is more up-to-date but is also more likely to contain errors, or a more-stable official version that may not have the very latest experimental changes but should work well for those who keep reasonably up-to-date with the official version.
This seems to me to be somewhat of a fiction, and to me an unhealthy one. It is not the "unofficial repository." It is the "development repository from which releases are made." We (those of us on this list) should probably all be reviewing commits to the repo in realtime and vendors should be encouraged to pull releases from it; at least if there are no other significant changes to release dynamics. To facilitate this, it would help if there was a monotonic identifier that increased for each commit in-between releases (VERSION=2015e+20150701a perhaps, corresponding to 9ebb8da281487886d4110388eb139578c72d1176, the first commit on July 1 (UTC)). I don't know if that is something reasonable to require of Paul. (And, unfortunately, I don't think there's a good git mechanism for it.) But really I think the complaint is one of consistency and reliability. If a vendor could reliably say, "I can expect a tzdata release to follow within 14 days after a change to a rule that takes effect 14-90 days out, within 30 days after a change to a rule that takes effect 90-180 days out, ..." then the vendor can decide in an informed fashion whether to wait for 2015f or just use 2015e+20150701a. Today, it's very hard for a vendor to predict whether they should wait an unbounded time for a release or should move forward outside the release process. Could the rules be made a little more clear (constraining the maintainer's flexibility, unfortunately)? --jhawk@mit.edu John Hawkinson
On Jul 11, 2015, at 1:40 PM, John Hawkinson <jhawk@MIT.EDU> wrote:
I think Deb Goldsmith is right and the tz db needs to change its release dynamics, which could happen in a few ways. But it could also improve the documentation of the release dynamics.
I think we should hope that tzdist can get deployed before major vendors find a "magic bullet" to speed up their OS releases.
Or to avoid having to bundle tzdb updates with a full-blown OS release.
As such, it's not compelling at this juncture (with tzdist around the corner?)
How "around the corner" is it?
to ask vendors to do that -- even if it were possible, which I think it really isn't.
Why do you think tzdb updates are different from printer driver updates?
I note, Guy, that you didn't respond to my comments about what the tz distribution can do. Even if you can get a few major vendors to solve this, you're unlikely to get many to do it quickly. So getting tz's own house in order (i.e. more predictable; better clarity on release engineering; etc.) is worth doing. Do you disagree? Guy Harris <guy@alum.mit.edu> wrote on Sat, 11 Jul 2015 at 14:00:25 -0700 in <BEE38224-A7BB-45B6-9FCE-6CC8C4A6A93A@alum.mit.edu>:
Or to avoid having to bundle tzdb updates with a full-blown OS release. As such, it's not compelling at this juncture (with tzdist around
the corner?)
How "around the corner" is it?
I do not know.
to ask vendors to do that -- even if it were possible, which I think it really isn't.
Why do you think tzdb updates are different from printer driver updates?
Not to be cynical, but the biggest reason is that the vendors in question have a current mechanism for executing printer updates in a timely fashion and they do not have that for tzdata updates. Even if the technical mechanism could be the same (and I don't think it is), the politics are different, and politics in large enterprise companies are not trivially navigable. You can argue that such a system should be built, but then a plausible response is that that engineering effort should be spent on tzdist. You might say that extending the printer mechanism to cover timezones should be ~0 work, but that seems unlikely to be something that the folks holding the pursestrings would believe, even if it were true. In another analysis, customers who spend money on a printer that doesn't work get upset, and they complain to both their OS vendor and their printer vendor (who is concerned about revenue), which leads to revenue-based incentives (indirect and direct) to get it right. On the other hand, users do not have to spend money for timezones, and thus they are disconnected from the financials. And users with wrong timezones for their country solve the problem some other way and move on -- change the zone or change the clock. We could also talk about how printer drivers are really an issue for "early adopters," but there is no analagous category for timezones (time travelers?). Anyhow, I don't disagree that "it would be great" if vendors adopted a more rapid mechanism to deploy timezone updates. Or that they implemented tzdist faster. Or implemented an interim measure prior to tzdist. I just don't think it is easy. And even if it is easy and the vendors are wrong about it being hard, convincing them of this is not very likely. The tz project should do what it can do to solve this problem, even as vendors work to do so as well. And tz can do that by having more predictable release timings, and making it easier to use the development tree. --jhawk@mit.edu John Hawkinson
On Jul 11, 2015, at 2:53 PM, John Hawkinson <jhawk@MIT.EDU> wrote:
I note, Guy, that you didn't respond to my comments about what the tz distribution can do. Even if you can get a few major vendors to solve this, you're unlikely to get many to do it quickly. So getting tz's own house in order (i.e. more predictable; better clarity on release engineering; etc.) is worth doing. Do you disagree?
No, I don't - that's why I didn't respond. I just don't want to let the vendors completely off the hook here. There are a number of things they could do to improve the handling of the tzdb. Apple's done a lot more than most vendors (they have the only UN*X time-zone-selection GUI that doesn't just throw the tz ids, or slightly prettified versions of the tz ids, at the user, and they have a version of localtime() etc. that doesn't assume that you can load up the tzdb entry at program startup time and never worry about it afterwards), but it'd be nice if they could do more (although, as noted below, the localtime() etc. implementation isn't *quite* as good as it could be, unless I've missed something).
Guy Harris <guy@alum.mit.edu> wrote on Sat, 11 Jul 2015 at 14:00:25 -0700 in <BEE38224-A7BB-45B6-9FCE-6CC8C4A6A93A@alum.mit.edu>:
Or to avoid having to bundle tzdb updates with a full-blown OS release. As such, it's not compelling at this juncture (with tzdist around
the corner?)
How "around the corner" is it?
I do not know.
If it's not *that* around the corner, perhaps it might be worthwhile for vendors to consider a mechanism for updating time zone data that doesn't require a full-blown OS update, especially given that time zone/DST updates often occur on schedules that don't line up very well with OS update schedules.
to ask vendors to do that -- even if it were possible, which I think it really isn't.
Why do you think tzdb updates are different from printer driver updates?
Not to be cynical, but the biggest reason is that the vendors in question have a current mechanism for executing printer updates in a timely fashion and they do not have that for tzdata updates. Even if the technical mechanism could be the same (and I don't think it is),
Why do you not think it is? "Here's a bunch of files; replace the current versions of these files, and deliver whatever indications are necessary to get currently running software to update whatever it has to update in response to that". The latter of the two is the only part that's different from updating printer drivers (and, if those drivers are loaded into currently-running software, even *that* might not be different, as that software might have to be told to unload and reload the existing driver code/printer description file/etc.). Currently, OS X's localtime() code wouldn't recognize the tzdb update when it gets a "com.apple.system.timezone" notify(3) notification, so the indication would be a "do a reboot" indication; were it not only to lstat() /etc/timezone and check whether it changed, but stat() it to find out whether what it points to changed, even *that* wouldn't be necessary - just deliver a "com.apple.system.timezone" notification and notifications for the file or files that changed. (The lstat() is currently only done if a "system time zone changed" notification has been delivered; the same would be true of the stat(), so it's not as if it'd add frequent file system operations.)
the politics are different,
Are different, or might be different?
and politics in large enterprise companies are not trivially navigable.
You can argue that such a system should be built, but then a plausible response is that that engineering effort should be spent on tzdist.
You might say that extending the printer mechanism to cover timezones should be ~0 work,
Actually, I'd say that there might not be a "printer mechanism" at all. Given that Apple updates printer drivers, digital camera RAW image software, Web browsers, etc. outside of the normal "here's a new dot release of the OS" mechanism, I suspect there's an underlying more general update mechanism currently used for several purposes. And given that many Linux distributions don't have a "here's a new dot release of the OS" mechanism, they have a general "update these components" mechanism, there's *definitely* a more general update mechanism there. So the cost there might just be the cost of packaging a tzdb update in the mechanism in question. I would not be surprised to hear that the Linux distributions in question *already* do that, so that changes to the update software on the update servers, the update client, and the process for doing tzdb updates aren't necessary. There would probably be some cost for Apple doing it, but I'm not convinced that it would necessarily be enough to prevent it from being done - it might not require Tim Cook's approval. Perhaps there *are* OSes where there's no mechanism for updating individual components out of band, some of whose users might have to do the tzdb update themselves if the government of a country whose time zones they need to deal with decides, on very short notice, to change the way time is kept in that country.
but that seems unlikely to be something that the folks holding the pursestrings would believe, even if it were true.
In another analysis, customers who spend money on a printer that doesn't work get upset, and they complain to both their OS vendor and their printer vendor (who is concerned about revenue), which leads to revenue-based incentives (indirect and direct) to get it right.
On the other hand, users do not have to spend money for timezones, and thus they are disconnected from the financials. And users with wrong timezones for their country solve the problem some other way and move on -- change the zone or change the clock.
So why are people from OS suppliers complaining here about updates not being provided by the tzdb maintainers in a sufficiently timely fashion, if the users don't push back if the time zone information isn't up-to-date?
We could also talk about how printer drivers are really an issue for "early adopters,"
Early adopters of a particular printer model? I bought the printer we have back in the late 1990's, and I think I got driver updates for it at least a few years ago, perhaps sooner.
Why do you not think it is? "Here's a bunch of files; replace the current versions of these files, and deliver whatever indications are necessary to get currently running software to update whatever it has to update in response to that". The latter of the two is the only part that’s different from updating printer drivers (and, if those drivers are loaded into currently-running software, even *that* might not be different, as that software might have to be told to unload and reload the existing driver code/printer description file/etc.).
That approach works for the Unix-level tz data. Unfortunately, it doesn’t work for the ICU open source library, which is a core component of OS X, iOS, Android, and other systems. Also, the relevant people at Apple are definitely aware that there is room for improvement to the current process. The fact remains, the more quickly IANA releases tz updates, the more quickly tz clients (not just Apple) can get those new versions into the hands of customers. By all means, we should take the time to make sure an update is solid, but I don’t think sitting on it on the chance it might change again is necessary, unless there’s some concrete evidence that it might change again. Deborah
On Jul 11, 2015, at 3:51 PM, Guy Harris <guy@alum.mit.edu> wrote:
On Jul 11, 2015, at 2:53 PM, John Hawkinson <jhawk@MIT.EDU> wrote:
I note, Guy, that you didn't respond to my comments about what the tz distribution can do. Even if you can get a few major vendors to solve this, you're unlikely to get many to do it quickly. So getting tz's own house in order (i.e. more predictable; better clarity on release engineering; etc.) is worth doing. Do you disagree?
No, I don't - that's why I didn't respond.
I just don't want to let the vendors completely off the hook here. There are a number of things they could do to improve the handling of the tzdb. Apple's done a lot more than most vendors (they have the only UN*X time-zone-selection GUI that doesn't just throw the tz ids, or slightly prettified versions of the tz ids, at the user, and they have a version of localtime() etc. that doesn't assume that you can load up the tzdb entry at program startup time and never worry about it afterwards), but it'd be nice if they could do more (although, as noted below, the localtime() etc. implementation isn't *quite* as good as it could be, unless I've missed something).
Guy Harris <guy@alum.mit.edu> wrote on Sat, 11 Jul 2015 at 14:00:25 -0700 in <BEE38224-A7BB-45B6-9FCE-6CC8C4A6A93A@alum.mit.edu>:
Or to avoid having to bundle tzdb updates with a full-blown OS release. As such, it's not compelling at this juncture (with tzdist around
the corner?)
How "around the corner" is it?
I do not know.
If it's not *that* around the corner, perhaps it might be worthwhile for vendors to consider a mechanism for updating time zone data that doesn't require a full-blown OS update, especially given that time zone/DST updates often occur on schedules that don't line up very well with OS update schedules.
to ask vendors to do that -- even if it were possible, which I think it really isn't.
Why do you think tzdb updates are different from printer driver updates?
Not to be cynical, but the biggest reason is that the vendors in question have a current mechanism for executing printer updates in a timely fashion and they do not have that for tzdata updates. Even if the technical mechanism could be the same (and I don't think it is),
Why do you not think it is? "Here's a bunch of files; replace the current versions of these files, and deliver whatever indications are necessary to get currently running software to update whatever it has to update in response to that". The latter of the two is the only part that's different from updating printer drivers (and, if those drivers are loaded into currently-running software, even *that* might not be different, as that software might have to be told to unload and reload the existing driver code/printer description file/etc.).
Currently, OS X's localtime() code wouldn't recognize the tzdb update when it gets a "com.apple.system.timezone" notify(3) notification, so the indication would be a "do a reboot" indication; were it not only to lstat() /etc/timezone and check whether it changed, but stat() it to find out whether what it points to changed, even *that* wouldn't be necessary - just deliver a "com.apple.system.timezone" notification and notifications for the file or files that changed. (The lstat() is currently only done if a "system time zone changed" notification has been delivered; the same would be true of the stat(), so it's not as if it'd add frequent file system operations.)
the politics are different,
Are different, or might be different?
and politics in large enterprise companies are not trivially navigable.
You can argue that such a system should be built, but then a plausible response is that that engineering effort should be spent on tzdist.
You might say that extending the printer mechanism to cover timezones should be ~0 work,
Actually, I'd say that there might not be a "printer mechanism" at all.
Given that Apple updates printer drivers, digital camera RAW image software, Web browsers, etc. outside of the normal "here's a new dot release of the OS" mechanism, I suspect there's an underlying more general update mechanism currently used for several purposes.
And given that many Linux distributions don't have a "here's a new dot release of the OS" mechanism, they have a general "update these components" mechanism, there's *definitely* a more general update mechanism there.
So the cost there might just be the cost of packaging a tzdb update in the mechanism in question. I would not be surprised to hear that the Linux distributions in question *already* do that, so that changes to the update software on the update servers, the update client, and the process for doing tzdb updates aren't necessary. There would probably be some cost for Apple doing it, but I'm not convinced that it would necessarily be enough to prevent it from being done - it might not require Tim Cook's approval.
Perhaps there *are* OSes where there's no mechanism for updating individual components out of band, some of whose users might have to do the tzdb update themselves if the government of a country whose time zones they need to deal with decides, on very short notice, to change the way time is kept in that country.
but that seems unlikely to be something that the folks holding the pursestrings would believe, even if it were true.
In another analysis, customers who spend money on a printer that doesn't work get upset, and they complain to both their OS vendor and their printer vendor (who is concerned about revenue), which leads to revenue-based incentives (indirect and direct) to get it right.
On the other hand, users do not have to spend money for timezones, and thus they are disconnected from the financials. And users with wrong timezones for their country solve the problem some other way and move on -- change the zone or change the clock.
So why are people from OS suppliers complaining here about updates not being provided by the tzdb maintainers in a sufficiently timely fashion, if the users don't push back if the time zone information isn't up-to-date?
We could also talk about how printer drivers are really an issue for "early adopters,"
Early adopters of a particular printer model? I bought the printer we have back in the late 1990's, and I think I got driver updates for it at least a few years ago, perhaps sooner.
On Jul 11, 2015, at 5:21 PM, Deborah Goldsmith <goldsmit@apple.com> wrote:
Why do you not think it is? "Here's a bunch of files; replace the current versions of these files, and deliver whatever indications are necessary to get currently running software to update whatever it has to update in response to that". The latter of the two is the only part that’s different from updating printer drivers (and, if those drivers are loaded into currently-running software, even *that* might not be different, as that software might have to be told to unload and reload the existing driver code/printer description file/etc.).
That approach works for the Unix-level tz data. Unfortunately, it doesn’t work for the ICU open source library, which is a core component of OS X, iOS, Android, and other systems.
Presumably ICU can, at least, reload whatever form of tzdata it uses when the system time zone changes (I didn't have to reboot my Mac when I flew from California to Pennsylvania a few years ago, and a lot of the GUI-based software I was using was presumably using ICU), so there is - at least in OS X's and presumably iOS's version of ICU - presumably at least *some* of the mechanism in place to allow it to update the information for the current time zone without having to restart the process. So why would updating ICU's time zone data not be doable with the same mechanism that could be used for UN*X's time zone data?
Also, the relevant people at Apple are definitely aware that there is room for improvement to the current process.
The fact remains, the more quickly IANA releases tz updates, the more quickly tz clients (not just Apple) can get those new versions into the hands of customers. By all means, we should take the time to make sure an update is solid, but I don’t think sitting on it on the chance it might change again is necessary, unless there’s some concrete evidence that it might change again.
Paul said:
I'd be surprised if a new version came out all that soon. The Uruguay change doesn't take effect for three months, so there's no rush for organizations that can turn around tz changes relatively quickly. Conversely, projects that take many months to upgrade will be late no matter what we do.
That being said, we shouldn't wait indefinitely for a new version.
so he's not proposing sitting on it forever. However, he also said:
Have we verified the upcoming Uruguay change? Not really, not nearly as much as (say) we verified the most-recent US change -- and even if we had better confirmation, the Uruguayan change is controversial and perhaps they'll change their minds.
so the question is how long should we wait to see if Uruguay changes their mind. And, given that:
Downstream users of the tz database need to be reasonably prompt in applying new releases anyway. Governments sometimes decide changes only a few days before they take effect, so if users care about timestamps, OS release schedules simply cannot require three-month delays. This is true regardless of whether we issue a new Uruguayan-related tz release this week or next week.
the only change to which I'd make is to replace "OS release schedules" with "OS supplier time zone data release schedules", as that wording leaves open the possibility of *not* tying time zone data releases to full OS releases. I, at least, think not tying them together is something worth considering, given that governments don't, in general, ask Apple and Oracle and HP and IBM and Red Hat and Novell and... when they should make time zone changes so as to avoid making any of them have to scramble to get a new release out the door or have to make their customers put up with several months of incorrect time zone data.
Presumably ICU can, at least, reload whatever form of tzdata it uses when the system time zone changes (I didn't have to reboot my Mac when I flew from California to Pennsylvania a few years ago, and a lot of the GUI-based software I was using was presumably using ICU), so there is - at least in OS X's and presumably iOS's version of ICU - presumably at least *some* of the mechanism in place to allow it to update the information for the current time zone without having to restart the process.
So why would updating ICU’s time zone data not be doable with the same mechanism that could be used for UN*X's time zone data?
Because they’re not the same thing. Capsule version: ICU has a data file. ICU is not currently architected to allow you to swap out the data file, or a portion of it, while a process using ICU is running. Selecting a different time zone from the existing data file is an entirely different matter from replacing some or all of the data file itself. Further information can be found at icu-project.org. Deborah
On Jul 11, 2015, at 5:47 PM, Guy Harris <guy@alum.mit.edu> wrote:
On Jul 11, 2015, at 5:21 PM, Deborah Goldsmith <goldsmit@apple.com> wrote:
Why do you not think it is? "Here's a bunch of files; replace the current versions of these files, and deliver whatever indications are necessary to get currently running software to update whatever it has to update in response to that". The latter of the two is the only part that’s different from updating printer drivers (and, if those drivers are loaded into currently-running software, even *that* might not be different, as that software might have to be told to unload and reload the existing driver code/printer description file/etc.).
That approach works for the Unix-level tz data. Unfortunately, it doesn’t work for the ICU open source library, which is a core component of OS X, iOS, Android, and other systems.
Presumably ICU can, at least, reload whatever form of tzdata it uses when the system time zone changes (I didn't have to reboot my Mac when I flew from California to Pennsylvania a few years ago, and a lot of the GUI-based software I was using was presumably using ICU), so there is - at least in OS X's and presumably iOS's version of ICU - presumably at least *some* of the mechanism in place to allow it to update the information for the current time zone without having to restart the process.
So why would updating ICU's time zone data not be doable with the same mechanism that could be used for UN*X's time zone data?
Also, the relevant people at Apple are definitely aware that there is room for improvement to the current process.
The fact remains, the more quickly IANA releases tz updates, the more quickly tz clients (not just Apple) can get those new versions into the hands of customers. By all means, we should take the time to make sure an update is solid, but I don’t think sitting on it on the chance it might change again is necessary, unless there’s some concrete evidence that it might change again.
Paul said:
I'd be surprised if a new version came out all that soon. The Uruguay change doesn't take effect for three months, so there's no rush for organizations that can turn around tz changes relatively quickly. Conversely, projects that take many months to upgrade will be late no matter what we do.
That being said, we shouldn't wait indefinitely for a new version.
so he's not proposing sitting on it forever. However, he also said:
Have we verified the upcoming Uruguay change? Not really, not nearly as much as (say) we verified the most-recent US change -- and even if we had better confirmation, the Uruguayan change is controversial and perhaps they'll change their minds.
so the question is how long should we wait to see if Uruguay changes their mind.
And, given that:
Downstream users of the tz database need to be reasonably prompt in applying new releases anyway. Governments sometimes decide changes only a few days before they take effect, so if users care about timestamps, OS release schedules simply cannot require three-month delays. This is true regardless of whether we issue a new Uruguayan-related tz release this week or next week.
the only change to which I'd make is to replace "OS release schedules" with "OS supplier time zone data release schedules", as that wording leaves open the possibility of *not* tying time zone data releases to full OS releases. I, at least, think not tying them together is something worth considering, given that governments don't, in general, ask Apple and Oracle and HP and IBM and Red Hat and Novell and... when they should make time zone changes so as to avoid making any of them have to scramble to get a new release out the door or have to make their customers put up with several months of incorrect time zone data.
On Jul 11, 2015, at 6:46 PM, Deborah Goldsmith <goldsmit@apple.com> wrote:
Capsule version: ICU has a data file. ICU is not currently architected to allow you to swap out the data file, or a portion of it, while a process using ICU is running.
Selecting a different time zone from the existing data file is an entirely different matter from replacing some or all of the data file itself.
So, if the rules for the current time zone change, you would have to log out and log in again (shutting down and restarting apps that might be using ICU) to make the change take effect? (Thanks to localtime() not working that way, a reboot shouldn't be necessary unless there are long-running processes using ICU *not* associated with a user session.) Hopefully that can be fixed at some point, unless it'd take longer to do so than it'll take for tzdist to be a thing *and* ICU will be able to cope with updates from tzdist without a process restart.
It's not just ICU. There are dozens of software frameworks and libraries that depend on tzdata and don't have automatic update mechanisms. Examples: PHP's integrated timezonedb package, Python's pytz library, Javascript's moment-timezone library, Java's time package and Joda Time, Net Noda time, etc... Many of these distribute packages through package managers such as pecl, pypi, npm, bower, etc. There's very rarely a built-in update mechanism. The developer of a project that uses one of these libraries has to periodically check for an update, apply it to their software, and redeploy or redistribute their software. The library vendors usually can't initiate this process until an official tzdata release posted at IANA. Our lead time should not be instantaneous, but we shouldn't wait till the last possible minute either. Somewhere in the middle is prefered.
From: guy@alum.mit.edu Date: Sat, 11 Jul 2015 18:55:17 -0700 To: tz@iana.org Subject: Re: [tz] Uruguay out of DST
On Jul 11, 2015, at 6:46 PM, Deborah Goldsmith <goldsmit@apple.com> wrote:
Capsule version: ICU has a data file. ICU is not currently architected to allow you to swap out the data file, or a portion of it, while a process using ICU is running.
Selecting a different time zone from the existing data file is an entirely different matter from replacing some or all of the data file itself.
So, if the rules for the current time zone change, you would have to log out and log in again (shutting down and restarting apps that might be using ICU) to make the change take effect? (Thanks to localtime() not working that way, a reboot shouldn't be necessary unless there are long-running processes using ICU *not* associated with a user session.)
Hopefully that can be fixed at some point, unless it'd take longer to do so than it'll take for tzdist to be a thing *and* ICU will be able to cope with updates from tzdist without a process restart.
On Jul 11, 2015, at 7:11 PM, Matt Johnson <mj1856@hotmail.com> wrote:
It's not just ICU. There are dozens of software frameworks and libraries that depend on tzdata
Presumably meaning "depend on their own copies of tzdata" (perhaps because they have to run on OSes that don't ship with tzdata, e.g. Windows and some versions of UN*X or, at least, older releases of those versions). ("date" depends, indirectly, on tzdata, but it doesn't ship with its own copy. :-)) If there are other reasons for maintaining their own copies of tzdata, perhaps improvements to the UN*X time APIs could help.
On 12/07/15 03:36, Guy Harris wrote:
It's not just ICU. There are dozens of software frameworks and libraries that depend on tzdata Presumably meaning "depend on their own copies of tzdata" (perhaps because they have to run on OSes that don't ship with tzdata, e.g. Windows and some versions of UN*X or, at least, older releases of those versions). ("date" depends, indirectly, on tzdata, but it doesn't ship with its own copy. :-))
If there are other reasons for maintaining their own copies of tzdata, perhaps improvements to the UN*X time APIs could help.
One aspect of all of this which keeps getting totally ignored is that data normalized using a particular set of tz rules needs to be processed with those rules before applying the CURRENT rules. One aspect of tzdist is that most people only expect a CURRENT set of tz rules and ignore that the information may not have been generated with those rules. The WAY of processing this material needs a proper overhaul and tzdist HAS the means of establishing if a piece of material may be subject to a change. This may be looking at an historic set of date ( for which pre-1970 rules may be important ) but even with current data as has already been stated here. If the diary for next year has been published using 'version a' then yes at some point that published data needs updating, but until that happens CURRENTLY one just gets duff data, while proper use of tzdist would flag that perhaps the meeting you are planning to go to may be an hour an hour adrift now. The major problem today is that much historic data has been created with the tzdata rules of that time but with no reference to just what those rules were, and so may well be inaccurate. So we need to get tzdist running with a single reliable data source, complete with all of it's history and then rebuild the rest of the infrastructure to respect that process. The Uruguay data would have been published by now, and diaries for next year that may be affected by the change would at least flag a potential difference. -- 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
Replying to an older message in the thread.. Enviado desde nuestro iPhone. On Jul 11, 2015, at 5:47 PM, Guy Harris <guy@alum.mit.edu> wrote:
That approach works for the Unix-level tz data. Unfortunately, it doesn’t work for the ICU open source library, which is a core component of OS X, iOS, Android, and other systems.
Presumably ICU can, at least, reload whatever form of tzdata it uses when the system time zone changes …
So why would updating ICU's time zone data not be doable with the same mechanism that could be used for UN*X's time zone data?
The cause is caching of data much more complex than typical un*x time services. You can in fact reload Icu without a process restart, but not while any threads are using any services or have service objects allocated. Also if a weekly calendar were in the middle of painting when an update came; it could be unexpected to see part of the week with a shifted offset. Even if there were a portable way to get notification of file/network updates an app would have opinions on how changes are made. It's as if I had "int a=3; sleep(); int b=3; if(a==b)…" I would not expect a and b to be different from each other, but that's what a tz rule change would do. In a modern highly composed application, when are you really sure that *all* libraries on all threads are ready for Uruguay's offset to change? That said, if anyone wants to jump in with ideas, ICU is open source and could with some engineering perhaps lend itself to experimental use of tzdist or other options. Let me know offline if anyone needs pointers on getting started. End plug. Steven.
On 07/11/2015 01:40 PM, John Hawkinson wrote:
This seems to me to be somewhat of a fiction, and to me an unhealthy one. It is not the "unofficial repository." It is the "development repository from which releases are made."
It's both, of course. There's no fiction here. The experimental github repository could be moved to another hosting site tomorrow, without affecting the official releases. In this sense it has the same role that the old SCCS repository did. The main difference is that the github repository is world-readable whereas the old SCCS repository was private.
it would help if there was a monotonic identifier that increased for each commit in-between releases (VERSION=2015e+20150701a perhaps, corresponding to 9ebb8da281487886d4110388eb139578c72d1176, the first commit on July 1 (UTC)). I don't know if that is something reasonable to require of Paul. (And, unfortunately, I don't think there's a good git mechanism for it.)
In the current experimental repository a monotonic identifier is the commit timestamp in UTC.
If a vendor could reliably say, "I can expect a tzdata release to follow within 14 days after a change to a rule that takes effect 14-90 days out, within 30 days after a change to a rule that takes effect 90-180 days out, ..."
Many releases are special cases, and I doubt whether tzdata redistributors could rely on such a specific formula in practice. The best we could say would be something along the lines of "we'll try to publish a new release a week before the change takes effect, but we can't promise this because sometimes governments give us even less notice than that". If redistributors can't broadcast changes to their users within a few days, their users will lose out on occasion. This would be true even if the tz project generated new releases with zero delay, so there's nothing the tz project can do to "fix" this. What needs to be fixed is the processes some redistributors use to propagate tz updates to their users' machines. Three months is far too long a delay. Updates clearly can be done reasonably quickly, within a matter of days not months, as shown by the redistributors like Ubuntu who are doing so. Yes, Apple and Google have far more users than Ubuntu but they can scale to those users. Yes, they have to deal with ICU but so do Ubuntu and the other guys. Yes, Google must communicate to its own downstream redistributors, but this problem can be addressed (see Debian and Ubuntu). None of these problems are fundamental obstacles to getting changes out far more quickly than what happens now, and this quickness is needed regardless of what the tz project does.
If redistributors can't broadcast changes to their users within a few days, their users will lose out on occasion. This would be true even if the tz project generated new releases with zero delay, so there's nothing the tz project can do to "fix" this. What needs to be fixed is the processes some redistributors use to propagate tz updates to their users' machines. Three months is far too long a delay. Updates clearly can be done reasonably quickly, within a matter of days not months, as shown by the redistributors like Ubuntu who are doing so.
We don’t live in an optimal world. 1. Governments make changes to their time zone rules with short notice and inadequate information. 2. IANA needs to collect the new information and update the tz database. That takes time. 3. Different vendors have different processes, and some take longer than others. We can’t do much about the first one. As I’ve already mentioned the relevant people at Apple are well aware that sooner is better when it comes to updates. I’m pretty sure our friends at Google are well aware of that too. Comparing the release processes of something like Android or iOS to those of Ubuntu is not helpful. They’re different products with different models. Perhaps in the future Google or Apple will be able to turn around time zone updates more quickly. We don’t live in that world yet. And none of that means that IANA shouldn’t strive to release updated tz data as soon as possible (but no sooner). Let’s all work on making our own parts better and faster. Deborah
On Jul 11, 2015, at 5:49 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 07/11/2015 01:40 PM, John Hawkinson wrote:
This seems to me to be somewhat of a fiction, and to me an unhealthy one. It is not the "unofficial repository." It is the "development repository from which releases are made."
It's both, of course. There's no fiction here.
The experimental github repository could be moved to another hosting site tomorrow, without affecting the official releases. In this sense it has the same role that the old SCCS repository did. The main difference is that the github repository is world-readable whereas the old SCCS repository was private.
it would help if there was a monotonic identifier that increased for each commit in-between releases (VERSION=2015e+20150701a perhaps, corresponding to 9ebb8da281487886d4110388eb139578c72d1176, the first commit on July 1 (UTC)). I don't know if that is something reasonable to require of Paul. (And, unfortunately, I don't think there's a good git mechanism for it.)
In the current experimental repository a monotonic identifier is the commit timestamp in UTC.
If a vendor could reliably say, "I can expect a tzdata release to follow within 14 days after a change to a rule that takes effect 14-90 days out, within 30 days after a change to a rule that takes effect 90-180 days out, ..."
Many releases are special cases, and I doubt whether tzdata redistributors could rely on such a specific formula in practice. The best we could say would be something along the lines of "we'll try to publish a new release a week before the change takes effect, but we can't promise this because sometimes governments give us even less notice than that".
If redistributors can't broadcast changes to their users within a few days, their users will lose out on occasion. This would be true even if the tz project generated new releases with zero delay, so there's nothing the tz project can do to "fix" this. What needs to be fixed is the processes some redistributors use to propagate tz updates to their users' machines. Three months is far too long a delay. Updates clearly can be done reasonably quickly, within a matter of days not months, as shown by the redistributors like Ubuntu who are doing so.
Yes, Apple and Google have far more users than Ubuntu but they can scale to those users. Yes, they have to deal with ICU but so do Ubuntu and the other guys. Yes, Google must communicate to its own downstream redistributors, but this problem can be addressed (see Debian and Ubuntu). None of these problems are fundamental obstacles to getting changes out far more quickly than what happens now, and this quickness is needed regardless of what the tz project does.
On Sat, Jul 11, 2015 at 7:49 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 07/11/2015 01:40 PM, John Hawkinson wrote:
it would help if there was a monotonic identifier that increased for each commit in-between releases (VERSION=2015e+20150701a perhaps, corresponding to 9ebb8da281487886d4110388eb139578c72d1176, the first commit on July 1 (UTC)). I don't know if that is something reasonable to require of Paul. (And, unfortunately, I don't think there's a good git mechanism for it.)
In the current experimental repository a monotonic identifier is the commit timestamp in UTC.
Alternatively, there actually is a pretty good Git mechanism for this: git-describe(1). Given a commit, git-describe finds the most recent previious tag and prints that tag, the number of commits since that tag, and the prefix of the given commit. For example, the current head of tzdata has 17 commits since the last release: $ git describe origin/master 2015e-17-ga86ca0f If the provided commit is tagged itself, then only the tag is printed: $ git describe 503ee68 2015e Finally, the output of git-describe can be fed back into git commands to refer to the original commit: $ git log -1 --oneline 2015e-17-ga86ca0f a86ca0f Improve comments for Halifax and Glace Bay Thanks for all the good work Paul! Regards, Chris
On 23 July 2015 at 23:26, Chris Rorvick <chris@rorvick.com> wrote:
Alternatively, there actually is a pretty good Git mechanism for this: git-describe(1). Given a commit, git-describe finds the most recent previious tag and prints that tag, the number of commits since that tag, and the prefix of the given commit.
Interesting. It would be nice if that could be incorporated in some way, but it relies on having the tags in your copy of the repository. For example, although my copy was one commit behind a few moments ago, it had been months since I'd pulled tags: $ git describe 2015a-69-ge6a6d02 $ git pull origin --tags ... $ git describe 2015e-16-ge6a6d02 -- Tim Parenti
On Thu, Jul 23, 2015 at 10:37 PM, Tim Parenti <tim@timtimeonline.com> wrote:
On 23 July 2015 at 23:26, Chris Rorvick <chris@rorvick.com> wrote:
Alternatively, there actually is a pretty good Git mechanism for this: git-describe(1). Given a commit, git-describe finds the most recent previious tag and prints that tag, the number of commits since that tag, and the prefix of the given commit.
Interesting. It would be nice if that could be incorporated in some way, but it relies on having the tags in your copy of the repository.
True, though the the default is to retrieve reachable tags on a fetch so your scenario seems somewhat exceptional. I assume you have `remote.<alias>.tagopt' set to --no-tags? Also, the prefix is actuallly not significant to Git: $ git log -1 --oneline one_plus_two_is-3-ge6a6d02 e6a6d02 Support %z in Zone formats So only the repo that generates the commit description needs to have tags; anyone can understand it (assuming they know about the commit.) If the use case is vendors publishing a version number to describe inter-release commits, this might be an insignificant issue. Regards, Chris
On 11 Jul 2015, at 20:42, Deborah Goldsmith <goldsmit@apple.com> wrote:
Meanwhile, the current situation is what it is, and we need to get tz updates to customers as quickly as we can. I wouldn’t want to see IANA rush data out before it’s vetted, or if further revisions seem likely, but neither do I want to see IANA sit on the data if it’s unlikely to change. IANA should not be making assumptions about how much time users of the tz database “ought to” need to get it to their customers.
I don’t think it is IANA that is sitting, or rushing, or making assumptions. My understanding is that IANA just hosts the mailing list and the data. The tz project is very much a volunteer effort. Please don’t make it seem more official than it is. I agree with Guy Harris on this. If Apple can distribute the digital camera raw updates more quickly/frequently than OS updates then it ought to be possible to do something similar for tz updates. I’m not knocking Apple here, I’m a happy user of their stuff. Even if this was an official IANA thing the problem would remain. The government of Elbonia is still going to decide to fiddle with their clocks next week even if IANA tells them they shouldn’t. Peter Ilieve
I've brought this up before, but I think it might be time to try to automate updates by taking user data from PC's, iPhone's etc. Some people misunderstood my suggestion before, but I'm old enough to remember a time before the internet, cell phones and when there was no such thing as color TV. We used to set these gadgets manually. To make this more clear, we should be taking input from users as to what time it is in each region and then analyze this data statistically to see if the deviation in each region is enough to warrant a change in the database. Where I wasn't clear about last time is that one would have to differentiate between data set by the database and data set by individual users. A dialog should come up on occasion to ask if the time displayed is correct for the location of the user. Corrections can be done using iteration until a certain accuracy level is reached (not all devices will be correct). I've considered that such power might be abused by trolls, but given that most users keep their clocks updated and will negate incorrect times, trolls in the minority would just be overridden. It's an idea in the early stages but if hashed out more completely, it can potentially save a lot of trouble. On Sat, Jul 11, 2015 at 4:18 PM, Peter Ilieve <peter@aldie.co.uk> wrote:
On 11 Jul 2015, at 20:42, Deborah Goldsmith <goldsmit@apple.com> wrote:
Meanwhile, the current situation is what it is, and we need to get tz
updates to customers as quickly as we can. I wouldn’t want to see IANA rush data out before it’s vetted, or if further revisions seem likely, but neither do I want to see IANA sit on the data if it’s unlikely to change. IANA should not be making assumptions about how much time users of the tz database “ought to” need to get it to their customers.
I don’t think it is IANA that is sitting, or rushing, or making assumptions. My understanding is that IANA just hosts the mailing list and the data. The tz project is very much a volunteer effort. Please don’t make it seem more official than it is.
I agree with Guy Harris on this. If Apple can distribute the digital camera raw updates more quickly/frequently than OS updates then it ought to be possible to do something similar for tz updates. I’m not knocking Apple here, I’m a happy user of their stuff.
Even if this was an official IANA thing the problem would remain. The government of Elbonia is still going to decide to fiddle with their clocks next week even if IANA tells them they shouldn’t.
Peter Ilieve
This of course doesn't do anything to predict the time of future updates. However, something might be done at the level of the UN to deal with future updates using special software. On Sat, Jul 11, 2015 at 5:03 PM, Zoidsoft <zoidsoft@gmail.com> wrote:
I've brought this up before, but I think it might be time to try to automate updates by taking user data from PC's, iPhone's etc. Some people misunderstood my suggestion before, but I'm old enough to remember a time before the internet, cell phones and when there was no such thing as color TV. We used to set these gadgets manually. To make this more clear, we should be taking input from users as to what time it is in each region and then analyze this data statistically to see if the deviation in each region is enough to warrant a change in the database. Where I wasn't clear about last time is that one would have to differentiate between data set by the database and data set by individual users. A dialog should come up on occasion to ask if the time displayed is correct for the location of the user. Corrections can be done using iteration until a certain accuracy level is reached (not all devices will be correct).
I've considered that such power might be abused by trolls, but given that most users keep their clocks updated and will negate incorrect times, trolls in the minority would just be overridden. It's an idea in the early stages but if hashed out more completely, it can potentially save a lot of trouble.
On Sat, Jul 11, 2015 at 4:18 PM, Peter Ilieve <peter@aldie.co.uk> wrote:
On 11 Jul 2015, at 20:42, Deborah Goldsmith <goldsmit@apple.com> wrote:
Meanwhile, the current situation is what it is, and we need to get tz
updates to customers as quickly as we can. I wouldn’t want to see IANA rush data out before it’s vetted, or if further revisions seem likely, but neither do I want to see IANA sit on the data if it’s unlikely to change. IANA should not be making assumptions about how much time users of the tz database “ought to” need to get it to their customers.
I don’t think it is IANA that is sitting, or rushing, or making assumptions. My understanding is that IANA just hosts the mailing list and the data. The tz project is very much a volunteer effort. Please don’t make it seem more official than it is.
I agree with Guy Harris on this. If Apple can distribute the digital camera raw updates more quickly/frequently than OS updates then it ought to be possible to do something similar for tz updates. I’m not knocking Apple here, I’m a happy user of their stuff.
Even if this was an official IANA thing the problem would remain. The government of Elbonia is still going to decide to fiddle with their clocks next week even if IANA tells them they shouldn’t.
Peter Ilieve
Guy Harris wrote:
I.e., how soon can various vendors - including *but not limited to* Apple and Google, given that there are also a number of significant computing devices out there that run neither Android nor iOS (and without which a lot of those Android and iOS machines won't be able to get very much interesting stuff from the Interwebs) - deploy mechanisms to update time zone files without having to spin an entire OS release just to note that Elbonia is changing to start using DST?
"Mechanisms" here includes both "a way by which an update can be pushed to machines, preferably without requiring a reboot" and "a way by which the vendor's process can treat a time zone data update as being more lightweight than a full OS release". As per my earlier mail, Apple, at least, have demonstrated that they can distribute other less-than-a-full-OS release update.
I think the upcoming tzdist protocol is a good way to update local tzdbs automatically, without interaction of an OS vendor, and with out having to roll out "firmware" or "system" updates just to get an updated version of the tzdb. Of course there is a daemon required to check for new versions and download the data, and eventually the runtime libraries need to be modified to become aware of update TZ rules on the fly, without reloading the libs or so. I'm not sure how the runtime libraries handle this right now, i.e. if tzdb updates are supplied as software updates. Martin
On Jul 11, 2015, at 1:19 PM, Martin Burnicki <martin.burnicki@burnicki.net> wrote:
I think the upcoming tzdist protocol is a good way to update local tzdbs automatically, without interaction of an OS vendor, and with out having to roll out "firmware" or "system" updates just to get an updated version of the tzdb.
What's the time frame for "upcoming" here? (Then there might have to be additional time added to make servers and clients available for the protocol....)
Of course there is a daemon required to check for new versions and download the data, and eventually the runtime libraries need to be modified to become aware of update TZ rules on the fly,
Unless your name is "Apple Inc.", in which case you did that a long time ago (I'm told by somebody in a position to know that the whole notify(3) mechanism was originally invented to support tzdb updates without having to restart processes).
without reloading the libs or so. I'm not sure how the runtime libraries handle this right now, i.e. if tzdb updates are supplied as software updates.
Presumably meaning "how the software suppliers handle this right now". Linux distributions don't seem to have "software updates" in the sense of "here's Fedora 24.1"; they seem to push individual components, so they can push tzdb updates separately from updates to anything else. I don't know what other suppliers do, but at least one supplier has demonstrated their ability to update parts of an OS independently of a full-blown Software Update.
On Jul 10, 2015, at 11:52 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 07/10/2015 12:30 PM, Deborah Goldsmith wrote:
I would love to be able to turn a tz release around in a week. That is not currently possible.
It is currently possible to do it in far less time than a week, for other operating systems.
And I think any OS that can release updates for printer drivers, camera RAW input processing modules, and Web browsers without bundling them into a complete OS release can also release updates for the timezone databases without bundling them into a complete OS release. (For the phones, tablets, set-top boxes, watches, etc., you could probably just push the update without even showing it to the user; localtime() etc. use notify(3) so that you shouldn't even need to reboot.) Perhaps other OSes using the tzdb should figure out how to do individual component updates and apply that to the tzdb.
For example, the 2014c release was turned around in about two hours by Debian, and in about three hours by Ubuntu; see <http://mm.icann.org/pipermail/tz/2014-May/020907.html>. This wasn't a complete new OS release: it was merely a patch, but that's good enough to solve the problem.
Exactly.
On 11/07/15 07:52, Paul Eggert wrote:
Two hours is pretty fast, and we can't expect redistributors to be that fast every time; even Debian doesn't do that. But it should be eminently doable to release an automatically-installable patch within a week. A three-month delay is waaayyy too long.
Much of the discussion on the specification on tzdist was disagreements on just what format things would take. This is the perpetual problem with many of these 'standards' and I can go on for hours about the various 'quality' standards that have absolutely nothing to do with the quality of the finished product as Mr. Ratner can testify. It is the QUALITY of the underlying data which is the problem, not getting it out fast, and there is nothing in tzdist to address that problem. The debate on the missing historic data will go on ... What we now need is a publisher who cleanly identifies just what range of tzdata it is providing and will use tzdist in a manor where some one like an international traveller switching on his mobile device after an 8 hour flight will be flagged that the time offset in the country they have just landed in has changed over night. As happens in some middle east countries. While the tzdist mechanism can pass on that information, itt has no mechanism for either creating the data, or handling the data once received. -- 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
On Jul 11, 2015, at 12:11 AM, Lester Caine <lester@lsces.co.uk> wrote:
Much of the discussion on the specification on tzdist was disagreements on just what format things would take. This is the perpetual problem with many of these 'standards' and I can go on for hours about the various 'quality' standards that have absolutely nothing to do with the quality of the finished product as Mr. Ratner can testify. It is the QUALITY of the underlying data which is the problem, not getting it out fast,
There are *several* problems, of which one is the difficulty of dealing with, sometimes on short notice, with a government changing DST rules on a schedule inconvenient both for the tzdb maintainers and the providers of software and equipment that uses the tzdb. ("Hi, we, the government of Elbonia, have decided to switch our country's civil time, starting at the end of next week!") That's the problem being discussed in this thread.
and there is nothing in tzdist to address that problem. The debate on the missing historic data will go on ...
What we now need is a publisher who cleanly identifies just what range of tzdata it is providing and will use tzdist in a manor where some one like an international traveller switching on his mobile device after an 8 hour flight will be flagged that the time offset in the country they have just landed in has changed over night.
That's the job of the provider of the OS for the mobile device; it's not the job of the database publisher, if they're not the provider of that OS, to arrange that OS in question pop up a "Surprise! The time changed overnight!" notification on the screen.
While the tzdist mechanism can pass on that information, itt has no mechanism for either creating the data,
That's the tzdb maintainer's job.
or handling the data once received.
That's the job of the software providers, including, but not necessarily limited to, the OS vendor (you might be using a third-party calendaring tool).
On 2015-07-10 13:30, Deborah Goldsmith wrote:
“Verified" is not Boolean. Of course it isn’t; that’s not what I was trying to say. If you want to substitute “reasonably confident of,” that’s fine. I understand there is a tradeoff between timeliness and confidence. Downstream users of the tz database need to be reasonably prompt in applying new releases anyway. Governments sometimes decide changes only a few days before they take effect, so if users care about timestamps, OS release schedules simply cannot require three-month delays. This is true regardless of whether we issue a new Uruguayan-related tz release this week or next week. As I’m sure you’re aware, considerations of time zone updates are not the only factor in determining OS release schedules. It’s unfortunately a fact of life that the further in advance an update is available, the more likely it is to be released in a timely fashion. I would love to be able to turn a tz release around in a week. That is not currently possible. Based on comments by others on this list, I suspect it’s not possible for them, either. I will investigate the option of proceeding based on the git repository, but of course an official release from IANA is much preferred.
On Jul 10, 2015, at 10:24 AM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 07/10/2015 09:15 AM, Deborah Goldsmith wrote:
is there any reason to wait once the data is verified? "Verified" is not Boolean. Have we verified the upcoming Uruguay change? Not really, not nearly as much as (say) we verified the most-recent US change -- and even if we had better confirmation, the Uruguayan change is controversial and perhaps they'll change their minds. Have we verified the upcoming Moldova change? More than Uruguay, but even there the start date for that change is sheer guesswork on my part. So it's quite possible that the proposed Moldovan and Uruguayan changes are wrong, at least in part. Also, there's overhead to making a release. Even when data can be 99.999% verified there is still benefit to having ten releases a year instead of fifty, if ten will do. Downstream users of the tz database need to be reasonably prompt in applying new releases anyway. Governments sometimes decide changes only a few days before they take effect, so if users care about timestamps, OS release schedules simply cannot require three-month delays. This is true regardless of whether we issue a new Uruguayan-related tz release this week or next week.
Don't recall seeing anyone post anything official from Uruguay gov on what their intent is. As they are dropping DST, perhaps they feel that not announcing DST is sufficient. When should the list or moderator feel comfortable that they are "officially" not going to announce DST? -- Take care. Thanks, Brian Inglis
Looks like it is permanent. The Uruguayan Chamber of Tourism writes (in Spanish) that the decree eliminates DST (not mentioning any specific year). Their main reason is that DST severely harms the tourism sector.
Source: http://www.camtur.com.uy/index.php/noticias/281-se-derogo-decreto-del-cambio...
Even Scharning http://time.is/
Debbie
On Jul 13, 2015, at 2:50 AM, Brian Inglis <Brian.Inglis@SystematicSW.ab.ca> wrote:
On 2015-07-10 13:30, Deborah Goldsmith wrote:
“Verified" is not Boolean. Of course it isn’t; that’s not what I was trying to say. If you want to substitute “reasonably confident of,” that’s fine. I understand there is a tradeoff between timeliness and confidence. Downstream users of the tz database need to be reasonably prompt in applying new releases anyway. Governments sometimes decide changes only a few days before they take effect, so if users care about timestamps, OS release schedules simply cannot require three-month delays. This is true regardless of whether we issue a new Uruguayan-related tz release this week or next week. As I’m sure you’re aware, considerations of time zone updates are not the only factor in determining OS release schedules. It’s unfortunately a fact of life that the further in advance an update is available, the more likely it is to be released in a timely fashion. I would love to be able to turn a tz release around in a week. That is not currently possible. Based on comments by others on this list, I suspect it’s not possible for them, either. I will investigate the option of proceeding based on the git repository, but of course an official release from IANA is much preferred.
On Jul 10, 2015, at 10:24 AM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 07/10/2015 09:15 AM, Deborah Goldsmith wrote:
is there any reason to wait once the data is verified? "Verified" is not Boolean. Have we verified the upcoming Uruguay change? Not really, not nearly as much as (say) we verified the most-recent US change -- and even if we had better confirmation, the Uruguayan change is controversial and perhaps they'll change their minds. Have we verified the upcoming Moldova change? More than Uruguay, but even there the start date for that change is sheer guesswork on my part. So it's quite possible that the proposed Moldovan and Uruguayan changes are wrong, at least in part. Also, there's overhead to making a release. Even when data can be 99.999% verified there is still benefit to having ten releases a year instead of fifty, if ten will do. Downstream users of the tz database need to be reasonably prompt in applying new releases anyway. Governments sometimes decide changes only a few days before they take effect, so if users care about timestamps, OS release schedules simply cannot require three-month delays. This is true regardless of whether we issue a new Uruguayan-related tz release this week or next week.
Don't recall seeing anyone post anything official from Uruguay gov on what their intent is. As they are dropping DST, perhaps they feel that not announcing DST is sufficient. When should the list or moderator feel comfortable that they are "officially" not going to announce DST?
-- Take care. Thanks, Brian Inglis
Source: http://www.camtur.com.uy/index.php/noticias/281-se-derogo-decreto-del-cambio...
That is a press release published by an organization lobbying for the change, and surely such a source is less reliable than the newspapers we're already citing. The whole thing is very mysterious, at least to this outsider.
On 2015-07-13 12:52, Paul Eggert wrote:
Source: http://www.camtur.com.uy/index.php/noticias/281-se-derogo-decreto-del-cambio... That is a press release published by an organization lobbying for the change, and surely such a source is less reliable than the newspapers we're already citing. The whole thing is very mysterious, at least to this outsider.
There has to be certain level of skepticism towards all journalistic reports that do not reference enacting legislation or provide a link to such, unless the source is known to be highly reliable e.g. ABC(AU), BBC(UK), CBC(CA), etc. The list members and maintainer rely on residents or knowledgeable outsiders to figure out where on governments' constantly evolving web sites current legislation can be found. Unfortunately the web links used for the previous change legislation are rarely sufficiently similar to that for the current change to allow the latest document to be found e.g. Uruguay southamerica zone America Montevideo comments: # http://www.presidencia.gub.uy/decretos/2004091502.htm # http://www.presidencia.gub.uy/_Web/noticias/2005/03/2005031005.htm # http://www.presidencia.gub.uy/_Web/decretos/2005/09/CM%20119_09%2009%202005_... # http://www.presidencia.gub.uy/_web/decretos/2006/09/CM%20210_08%2006%202006_... # http://archivo.presidencia.gub.uy/sci/decretos/2015/06/cons_min_201.pdf and depending on other relevant search terms used against that site, Google can at best find only PDFs for the 2004 decree, or a 2006 study about 2005 anti-smoking legislation. ;^> -- Take care. Thanks, Brian Inglis
participants (22)
-
Brian Inglis -
Chris Erskine -
Chris Rorvick -
Deborah Goldsmith -
enh -
Even Scharning -
Garrett Wollman -
Guy Harris -
John Hawkinson -
Lester Caine -
Martin Burnicki -
Matt Johnson -
Paul Eggert -
Paul Ganssle -
Paul_Koning＠dell.com -
Peter Ilieve -
Rich Gombert -
Steffen Thorsen -
Steve Allen -
Steven R. Loomis -
Tim Parenti -
Zoidsoft