As spec lead of JSR-310, the Java effort to enhance dates and times, I'm encoding TZDB data. In order to represent the different versions of the data, I'm using the tzdb naming scheme or year followed by letter, eg. 2010i. This version number is sorted alphabetically. Obviously, it is possible that there might be more than 26 releases of the data in one year. In order to maintain the alphabetical sort order, I'd like this list to determine a strategy for the unlikely event that this situation occurs. For example: 2010a 2010z 2010za 2010zb If the list does not arrange a strategy (and define it in the theory document), then JSR-310, or future maintainers, will have to make up our own approach for numbering the 27th and onwards releases. Opinions? thanks Stephen
The example seems reasonable to me; I plan to include a "Theory" change in the next batch. --ado -----Original Message----- From: jodastephen@googlemail.com [mailto:jodastephen@googlemail.com] On Behalf Of Stephen Colebourne Sent: Friday, April 23, 2010 7:18 To: Time zone list Subject: Time zone file naming scheme As spec lead of JSR-310, the Java effort to enhance dates and times, I'm encoding TZDB data. In order to represent the different versions of the data, I'm using the tzdb naming scheme or year followed by letter, eg. 2010i. This version number is sorted alphabetically. Obviously, it is possible that there might be more than 26 releases of the data in one year. In order to maintain the alphabetical sort order, I'd like this list to determine a strategy for the unlikely event that this situation occurs. For example: 2010a 2010z 2010za 2010zb If the list does not arrange a strategy (and define it in the theory document), then JSR-310, or future maintainers, will have to make up our own approach for numbering the 27th and onwards releases. Opinions? thanks Stephen
I'm guessing there's a reason a more "traditional" [ a, ..., z, aa, ab, ... az, ba, ... ] sort of sequence is unsuitable? Perhaps if we're going to change the convention, we ought to solve the issue by switching to numeric release identifiers: 2010-01, -02, ... --Ice Karma
I'm guessing there's a reason a more "traditional" [ a, ..., z, aa, ab, ... az, ba, ... ] sort of sequence is unsuitable?
Because 2010aa would come before 2010z in alphabetical order.
Perhaps if we're going to change the convention, we ought to solve the issue by switching to numeric release identifiers: 2010-01, -02, ...
That has the flaw of conflicting with the ISO scheme for naming months. If we want to go that way, we should probably just go all the way and append a full date to each release. --Ice Karma
On Tue, Apr 27, 2010 at 11:11, Andy Lipscomb <AndyLipscomb@decosimo.com>wrote:
Because 2010aa would come before 2010z in alphabetical order.
I knew there was a reason, thank you.
That has the flaw of conflicting with the ISO scheme for naming months. If we want to go that way, we should probably just go all the way and append a full date to each release.
Hm, and three digits would conflict with day of year naming, and four digits with year naming, ... Ugh. What a morass. So in a hypothetical future where we need more than 52 release identifiers, the 53rd would be "zza", the 79th "zzza"? I don't know how generally the rule is described in the relevant documents -- if it doesn't say what to do beyond "zz", we could well end up in the same kind of trouble again... --Ice Karma
On Apr 27, 2010, at 11:11 AM, Andy Lipscomb wrote:
If we want to go that way, we should probably just go all the way and append a full date to each release.
Sounds good to me. If, for some reason, we have to release more than one version on the same day, we could append a letter. (Presumably we won't have to release more than 27 versions in the same day.)
There is no need for all this fuss - last year was an unusually busy year (by far more updates than any other year), and it still didn't make it to z - the chances of ever needing to go past that are not really very high - though it certainly doesn't hurt to have a plan for what to do ready prepared. But worrying about > 50 updates in a year, when we've only ever reached 20 once or twice in all history is just a waste of effort. Just keep the current scheme with za coming after z, and if we ever reach (say) zm, we can have this discussion again. Until then, how about we just forget it? kre
participants (6)
-
Andy Lipscomb -
Guy Harris -
Ice Karma 「氷宿業」 -
Olson, Arthur David (NIH/NCI) [E] -
Robert Elz -
Stephen Colebourne