[tz] [musl] Re: Weird PST8PDT and EST5EDT behavior on Alpine Linux

[Rich Felker]

On Fri, Mar 08, 2024 at 09:46:24AM -0800, Paul Eggert wrote:
> On 2024-03-06 07:39, James Cloos via tz wrote:
> 
> >(I must say it was a bit anoying that the library kept the original
> >definition of EST5EDT et alia rathar than moving with the legislation.
> >But only a bit.)
> 
> So Openwrt uses pre-2007 US daylight saving rules for TZ='EST5EDT'?
> That's puzzling. I thought Openwrt is based on musl, which ignores
> DST for that TZ setting (a behavior that POSIX allows). I'm a bit
> curious as to what's going on there.

It's not so much that we ignore it (it's present in tzname[1], and
would get applied if you use mktime with tm_isdst=1), just that, in
the absence of a transition rule for it, it's never considered active.
I don't think this is a particularly good behavior (even though it is
allowed by POSIX) but nothing great has been proposed as an
alternative.

> >So I have to use EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00
> >for the timezone.  (The explicit /2:00:00 might be avoidable, but the
> >use of self documenting data can be beneficial.)
> 
> For a fully self-documented TZ setting you could use this:
> 
> <EST>+05:00:00<EDT>+04:00:00,M3.2.0/+02:00:00,M11.1.0/+02:00:00
> 
> However, this sort of thing tends to be error-prone; e.g., suppose I
> forgot a colon?
> 
> 'zic' attempts to generate the shortest equivalent TZ setting. On my
> machine /usr/share/zoneinfo/America/New_York ends with this
> equivalent:
> 
> EST5EDT,M3.2.0,M11.1.0

Yes, this i the form I've used in the past before we had zoneinfo
support.

Rich