Date: Tue, 01 May 2007 16:50:12 -0700 From: Paul Eggert <eggert@CS.UCLA.EDU>

"Olson, Arthur David \(NIH/NCI\) [E]" <olsona@dc37a.nci.nih.gov> writes:

...

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.

Yes, absolutely, and the change I proposed does not really support the Julian calendar; it's just a hack. A similar hack already "works" on some systems, e.g., on Solaris 8:

$ date -u +'%Y-%m-%d %H:%M UTC'; TZ=Athos-310 date +'%Y-%m-%d %H:%M Athos' 2007-05-01 23:46 UTC 2007-05-14 21:46 Athos

The above Solaris 8 behavior is accidental, due to no bounds checking of offset. This is changed in Solaris 10, where bounds checking is done. When the offset is out of bounds, TZ is considered incorrect, and an offset of zero is used as a default: $ date -u +'%Y-%m-%d %H:%M UTC'; TZ=Athos-310 date +'%Y-%m-%d %H:%M Athos' 2007-05-04 16:41 UTC 2007-05-04 16:41 Athos

so the question is whether the tz code should support similar hacks. (Note that the day-of-week will be wrong in the above example.)

...

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.

Yes, and I was reluctant to futz with localtime, to be honest, since this would require a change to the tz compiled format.

I think the primary justification for the proposed change is to generate "outlandish" compiled tz files, for use in testing. If it's not the intent to support outlandish values in compiled format, that fact should probably be documented, and files containing such values should be rejected by localtime.