Feedback from Java - JSR-310
I am the spec lead for JSR-310, the project to enhance time handling in the Java JDK. I'd like to give some feedback/information to this project. Naming JSR-310 supports the possiblity of multiple sources of time zone information. The data here is considered to be the default. I've referred to this group as "TZDB" (rather than "Olson" as in some sources). Let me know if you're unhappy with the "TZDB" name. File format The format of the time zone data files (zic.8.txt) could do with some clarifications/simplifications. (ie. can the document be updated?) Rule - FROM - "The word minimum (or an abbreviation)" should be changed to "The word minimum or min". Similarly with maximum. At the moment, the spec is silent about what happens for the letter "m" which is a valid abbreviation of "minimum" and "maximum". The spec also allows oddities like "mini". Rule - TO - "the word only (or an abbreviation)" - please drop the abbreviation part. Only the full word is used in the data, never the abbreviation. Rule - IN - "Names the month in which the rule takes effect. Month names may be abbreviated.". This should specify that the month names are English. Currently, only the three letter abbreviation is used. The spec also allows oddities like "Januar" and ambiguities like "J". Can the spec be limited to just the 3 letter form? Rule ON - similar comment for day of week. Again the suppiled files only use the 3 letter abbreviated form. Can the spec be limited to just the 3 letter form? I didn't notice any specific comment about case - is the input case sensitive? thanks, Stephen
Below is an addition to zic.8 that might cover the concerns raised. Zic is now liberal in what abbreviations it accepts; since we can't know whether others have used this liberality, I'm inclined to keep it. --ado .PP Names (such as month names) must be in English and are case insensitive. Abbreviations, if used, must be unambiguous in context.
I understand the problem. How about something to indicate that abbreviations less than 3 characters are strongly discouraged? Could you also address case sensitivity? For Java, I may only handle the full and 3 letter versions, plus the full word "only". Stephen On 16 March 2010 17:16, Olson, Arthur David (NIH/NCI) [E] <olsona@dc37a.nci.nih.gov> wrote:
Below is an addition to zic.8 that might cover the concerns raised.
Zic is now liberal in what abbreviations it accepts; since we can't know whether others have used this liberality, I'm inclined to keep it.
--ado
.PP Names (such as month names) must be in English and are case insensitive. Abbreviations, if used, must be unambiguous in context.
Hi Olson, As per POSIX standard timezone variable should be updated by tzset(), but its obvious that timezone values depends on what is the current time and during tzset() we won't be knowing the current time. So, for many countries, we are getting a wrong values for timezone and altzone for the current time. Hence is it possible to update the timezone and altzone values in localtime(), so atleast after calling the localtime we would be getting the correct values for both of these variables? The other solution would be to call time() in tzset(), and update the altzone, timezone variables in tzset itself. This will have little performance overhead, but we would be having a accurate values w.r.t current system time. This new feature could be under a #ifdef macros, so it can be enabled only for the people who are wants these variables to be updated in tzset itself but with a performance penalty. Also, is there any way available to get accurate values for these variables with the current version of the code? Thanks, Madhu. _________________________________ Madhusudanan Kandasamy AIX BOS Development, IBM Bangalore, EGL D block 6th Floor.
participants (3)
-
Madhusudanan Kandasamy -
Olson, Arthur David (NIH/NCI) [E] -
Stephen Colebourne