[tz] 2013g - Morocco

[Russ Allbery]

Lester Caine <lester at lsces.co.uk> writes:

> Of cause while the number of people affected by 'pre-history' dates with
> time is not so great, nowadays the 2038 rollover has to be taken
> seriously, and anybody still stuck with software affected by it needs to
> be considering the problem. With mortgages and pension dates for many
> people well beyond this any mainstream system that has not already
> switched to 64 bit timestamps are already unusable?

The problem with some specific time zones, like Morocco, is that the time
of DST is based on calculations that the tz software is not capable of
representing as rules or doing internally.  See the large comment in front
of that zone.  Instead, external software is used to generate the
year-by-year rules going forward up to some (fairly arbitrary) cut-off
point.  (Even those are an approximation in this case and will probably
require some last-minute fiddling in some years.)

Obviously, we don't want to do that until the end of time (particularly
since time has no end), but 2038 is getting closer, so maybe that isn't
the best cut-off point any more.  It might be interesting to do something
like generate the rules 50 years into the future and automate some way of
adding another year of rules each year.

That said, Paul's proposed approach (if I understood it correctly) is to
add an approximate static rule using the calculations the tz software can
represent as rules for dates past 2038, and I suspect that, for right now,
that will be good enough for most practical purposes.  (It will become
less useful the closer we get to 2038, of course.)

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>