"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 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.