proposed change to 'zic' to support "outlandish" offsets

[Paul Eggert]

"Olson, Arthur David \(NIH/NCI\) [E]" <olsona at 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.