[darcs-users] darcs patch: Resolve issue1311: Use time zones from GNU coreutils; ...

Trent W. Buck trentbuck at gmail.com
Thu Jan 15 23:43:19 UTC 2009


Dave Love <fx at gnu.org> writes:

> Eric Kow <kowey at darcs.net> writes:
>
>> Hi Dave,
>>
>> On Tue, Jan 13, 2009 at 11:07:25 +1100, Trent W. Buck wrote:
>>> On my Debian system, at least, there is a "tzdata" package which has a
>>> whole bunch of timezones in it.  Could these be used (possibly by means
>>> of the FFI)?
>
> I'm not sure you could use the data very conveniently, but you'd need
> a portable solution for darcs anyhow.

Certainly; but I also have no problem with providing superior support to
the systems that have the appropriate libraries.  If the appropriate
timezone libraries aren't available, a hard-coded list could be used as
a fallback.  Note that I'm assuming the timezone data is only needed
when formatting information for display, i.e. the on-disk format is UTC.

> Maybe autoconf/gnulib provides clues, but I don't know whether it's
> worthwhile worrying.  I assume what's good enough for date(1) is
> reasonable

I know that GNU date can handle timezones like

    $ TZ=Australia/Melbourne date
    Fri Jan 16 10:34:11 EST 2009
    $ TZ=Australia/Perth date
    Fri Jan 16 08:34:16 WST 2009

Note that both of these timezones are not simple hourly offesets --
there is daylight savings (summer time) to take into account, and the
start and end of daylight savings is subject to governmental whim (which
is why the tzdata package is updated half a dozen times each year).  In
some recent cases the daylight savings rules have been changed LESS THAN
A MONTH before they actually came into effect, which is why I worried
about keeping in sync / up to date.

Hmm, perhaps this is all moot because TZ=XXX is handled outside of
Darcs/GHC automatically by some generic "get local time" procedure.  I
notice that GNU date can't read back in the timezone it prints above:

    $ date -d 'Fri Jan 16 08:34:16 WST 2009'
    date: invalid date `Fri Jan 16 08:34:16 WST 2009'

>, and it does cover the globe with normal and daylight-saving zones

I don't see how the current mechanism handles daylight savings... unless
other governments have two separate timezones XXX and XXY, both at
constant time offsets, and switch between them on some arbitrarily
changing day each year...

> It seems reasonable to me, but I'm not a (darcs) maintainer.  It is a
> definite improvement extending the coverage in a reasonable way.

Agreed; I'm certainly not trying to devalue your improvement, I'm just
throwing ideas around for further improvement.



More information about the darcs-users mailing list