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

[Robbin Kawabata]

> Date: Tue, 01 May 2007 16:50:12 -0700
> From: Paul Eggert <eggert at CS.UCLA.EDU>
> 
> "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

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.