Hello, I've been following this discussion with interest, and we have discussed it a bit on the ICU mailing list (which is an application library which does time zone and calendar calculations, among other things). What would be ideal is not to change the system clock to be 'back', but to have the default calendar used by all formatters/ parsers to be a Julian one. ( i.e. as opposed to Gregorian, Japanese, etc. ) . One major benefit of this is that otherwise communication in and out (such as email dates..) will be all wrong. Time zone calculations could be simply done according to the Gregorian calendar ( to not affect either ICU or TZ infrastructure ) with the gregorian dates for changeover, whether the intended changeovers are in J or G time. (similar to how Israel time is handled, for example.) In other words, Athos time's zone rules could be in the TZ database according to the Gregorian dates of DST changes. Or would it follow Greece's DST rules? I think that having an outlandish offset would complicate things more than simply recalculating day of week, day of month, etc. based on a different calendar system, as if it were the Hebrew or Islamic or Hindi calendar. Regards, Steven http://icu-project.org On 01 Mej 2007, at 06:37, Olson, Arthur David ((NIH/NCI)) [E] wrote:
I don't know about Mt. Athos in particular; the general case of trying to support Julian dates is complicated by needing to change the day-of-month associated with a time_t value without changing the day-of-week associated with the value.
The advent of the 64-bit time_t extends the range of time_t values to include historical periods when the Julian calendar was in effect. It may or may not be worthwhile to try to change the handling of Julian-era time_t values; doing so would seem to require changes to both zic and to localtime.
--ado
-----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Monday, April 23, 2007 6:37 PM To: tz@lecserver.nci.nih.gov Cc: mgpeter@pcc-services.com; evdokimos@gmail.com Subject: proposed change to 'zic' to support "outlandish" offsets
Currently zic allows only GMT offsets in the range -24:00 to 24:00. And yet the recent query about Mt. Athos led me to think that in some cases it can be useful to allow GMT offsets outside the range, to approximate the Julian calendar. And at any rate zic should be able to generate whatever offset can be stored in the standard tz file format, if only for testing purposes.