This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] BZ#14080: Fix daylight time change for the US


> I dug out my 1988 book, and there is no specification calling for US
> law; US law is mentioned in the Rationale in passing as something
> that the format accommodates.
> 
> In fact, the stance (then and now) is that if there is no rule specified,
> the implementation gets to decide how to handle the rule.

Thanks for checking.  My memory is certainly unreliable even on subjects
not going back 24 years.

I think the ideal implementation-defined resolution for us would be to use
something table-driven for this case.  That is, "TZ=fooNbar" would obey the
N, the "foo", and the "bar", but refer to some canonical tzdata file for
the rules to follow.  Given the style of the tzdata format I'm not sure
exactly how this would work.  Perhaps it's as simple as computing a bias to
apply to the transition times in the file, which would mean that we encode
both a canonical tzdata file name and the knowledge of what that file's
baseline GMT offset is (i.e. "US/Eastern" and 5 hours west).  Of course,
we'd still need a fallback when the file is not found.  But at least in the
normal case we wouldn't be relying on library or program binaries made long
ago to encode rules that can change over time.

That is certainly more work than occasionally fiddling the default
parameters fed into the POSIX rule engine.  I don't expect anyone to jump
on it right quick.  But perhaps we should file a bug suggesting that for
the future unless everybody thinks it's a stupid idea.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]