Estimate for a new tzdb release with Brazil rules.
Wanted to request a follow-up to an earlier comment https://mm.icann.org/pipermail/tz/2019-April/027877.html <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.o...> . Specifically, “No rush for a new tzdb release (but of course we'll want something out before October :-)”. Do we have an estimate for when the new tzdb release might be available containing the Brazil rules? Is there any way I can request this be updated sooner than later? Understand there was a patch attached in an earlier thread. My company would ideally prefer to align with a more formal release cadence to get these changes. Thanks! -- Pramoth
On 5/10/19 8:45 AM, Pramoth Murali wrote:
Do we have an estimate for when the new tzdb release might be available containing the Brazil rules?
Not really. As a general rule we don't do release schedules.
Is there any way I can request this be updated sooner than later?
Yes, and you just did. :-)
My company would ideally prefer to align with a more formal release cadence to get these changes.
You can test or deliver systems based by using the tzdb development repository, which you can get as described in: https://data.iana.org/time-zones/tz-link.html It even comes with a version number; run the command 'make version'. It currently has the proposed patches for Brazil.
Hi everybody, Paul, I understood your explanation, but I would like to endorse the request. =) Here, we have a lot of customers in the area of health care in Brazil and many features in the system include scheduling, so, we need to update the system as early as possible. For many reasons, use the development repository is not easy for us. Thank you. Em sex, 10 de mai de 2019 às 19:41, Paul Eggert <eggert@cs.ucla.edu> escreveu:
On 5/10/19 8:45 AM, Pramoth Murali wrote:
Do we have an estimate for when the new tzdb release might be available containing the Brazil rules?
Not really. As a general rule we don't do release schedules.
Is there any way I can request this be updated sooner than later?
Yes, and you just did. :-)
My company would ideally prefer to align with a more formal release cadence to get these changes.
You can test or deliver systems based by using the tzdb development repository, which you can get as described in:
https://data.iana.org/time-zones/tz-link.html
It even comes with a version number; run the command 'make version'. It currently has the proposed patches for Brazil.
On 2019-05-13 11:35, Rodrigo Brüning Wessler wrote:
Em sex, 10 de mai de 2019 às 19:41, Paul Eggert escreveu:
On 5/10/19 8:45 AM, Pramoth Murali wrote:
Do we have an estimate for when the new tzdb release might be available containing the Brazil rules? Not really. As a general rule we don't do release schedules. Is there any way I can request this be updated sooner than later? Yes, and you just did. :-) My company would ideally prefer to align with a more formal release cadence to get these changes. You can test or deliver systems based by using the tzdb development repository, which you can get as described in: https://data.iana.org/time-zones/tz-link.html It even comes with a version number; run the command 'make version'. It currently has the proposed patches for Brazil. I understood your explanation, but I would like to endorse the request. =) Here, we have a lot of customers in the area of health care in Brazil and many features in the system include scheduling, so, we need to update the system as early as possible.> For many reasons, use the development repository is not easy for us. Asking the *volunteer* maintainers to hurry up are the wrong people to ask to provide the info sooner. Have your national airline, IT, and travel orgs, vendors, CIOs, and your own companies demand *your paid* senior bureacrats, civil servants, politicians, and ministers to notify this list directly <tz@iana.org> about any change to time regulations, with a web link to their online published legislation, and do so with as many months notice as possible, as they would with e.g. tax legislation because these changes also have many legal impacts, to allow Apple, Google, MS, IBM/RedHat, and every company and distro affected to prepare updates in advance.
Whatever the volunteer maintainers do is irrelevant when countries don't directly send links to legal notices of changes to this mailing list, leaving those who participate here to hopefully notice mentions of legislation, suggest and implement patches to the development repo, generate the official releases, have all the downstream distros, vendors, libraries, and apps maintainers download, apply, build, and test changes, then distribute them to every device owner in the world. In face of the current reality of politicians making changes with no notice, you really have to make a choice: improve and speed up your processes, or change your policy about when and where you get the data, or ideally both, as well as berating bureacrats and politicians for more evidence of their inability to adequately plan, as evidenced in their abysmal records on government IT projects, many of which are abandoned and never implemented. Perhaps we should have a stated public release schedule: we will have at least two scheduled releases a year, in January and July, including all changes enacted by their respective goverments before the previous July and January respectively. *"Lack of planning on your part does not constitute an emergency on my part!"* -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
Rodrigo Brüning Wessler wrote:
For many reasons, use the development repository is not easy for us.
Whatever the reasons are, in the long run it should be better to fix those bottlenecks than to worry overmuch about whether there will be an official release now or some weeks from now. There shouldn't be that much trouble testing and/or using a version named "2019a-14-g9e498e2" as opposed to testing and/or using a version named "2019b".
Date: Mon, 13 May 2019 23:52:43 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <89f9d06f-7cfc-0fea-e503-db89d795a693@cs.ucla.edu> | There shouldn't be that much trouble testing and/or using [...] When I once thought I might try that, I got told "git: command not found" I have no interest whatever in installing that thing, just for this. kre
On Tue, 14 May 2019 at 07:53, Paul Eggert <eggert@cs.ucla.edu> wrote:
Rodrigo Brüning Wessler wrote:
For many reasons, use the development repository is not easy for us.
Whatever the reasons are, in the long run it should be better to fix those bottlenecks than to worry overmuch about whether there will be an official release now or some weeks from now. There shouldn't be that much trouble testing and/or using a version named "2019a-14-g9e498e2" as opposed to testing and/or using a version named "2019b".
FYI, the Java definition says this when querying the list of available versions: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/zone/...) * The exact meaning and format of the version is provider specific. * The version must follow lexicographical order, thus the returned map will * be order from the oldest known rules to the newest available rules. * The default 'TZDB' group uses version numbering consisting of the year * followed by a letter, such as '2009e' or '2012f'. The ordering allows the versions to be sorted, and the latest one selected. If users want to have their own versions, I'd strongly suggest something sortable, not something based off a git hash, such as 2019a-patched-2019-05-14. (In any normal Java release, there is only ever one version present, so it could be argued the point is moot. But the spec does allow for there to be multiple versions as it is an extension point, so the issue could arise) Stephen
On 5/14/19 2:49 AM, Stephen Colebourne wrote:
FYI, the Java definition says this when querying the list of available versions: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/zone/...)
* The exact meaning and format of the version is provider specific. * The version must follow lexicographical order, thus the returned map will * be order from the oldest known rules to the newest available rules. * The default 'TZDB' group uses version numbering consisting of the year * followed by a letter, such as '2009e' or '2012f'.
The current tzdb release numbering scheme allows for more than 26 releases per year. tz-link.html says: Since 1996, each version has been a four-digit year followed by lower-case letter (<samp>a</samp> through <samp>z</samp>, then <samp>za</samp> through <samp>zz</samp>, then <samp>zza</samp> through <samp>zzz</samp>, and so on). As that sentence suggests, we may change the release numbering scheme in the future (we've changed it in the past). That would not be a casual decision of course.
The ordering allows the versions to be sorted, and the latest one selected. If users want to have their own versions, I'd strongly suggest something sortable, not something based off a git hash, such as 2019a-patched-2019-05-14.
The default numbering scheme for non-release versions is sortable, although one should use something like GNU strverscmp rather than classic strcmp. For example, "2019a-14-g9e498e2" is the version number for 14 commits since 2019a. The Java documentation should probably be updated to reflect the above. At least it should mention the possibility of "2019za" (shudder).
On Tue, 14 May 2019 at 17:50, Paul Eggert <eggert@cs.ucla.edu> wrote:
The Java documentation should probably be updated to reflect the above. At least it should mention the possibility of "2019za" (shudder).
It should, but the hassle of making a change like that would be very painful. The main point is to ensure that the ID people use for patched versions should be sortable. Stephen
participants (6)
-
Brian Inglis -
Paul Eggert -
Pramoth Murali -
Robert Elz -
Rodrigo Brüning Wessler -
Stephen Colebourne