Re: RFS: python3-dateutil
- To: firstname.lastname@example.org
- Subject: Re: RFS: python3-dateutil
- From: Jakub Wilk <email@example.com>
- Date: Sun, 1 Apr 2012 11:53:49 +0200
- Message-id: <[🔎] 20120401095349.GA9061@jwilk.net>
- Mail-followup-to: firstname.lastname@example.org
- In-reply-to: <CAOvn4qie-yBr-novh71RXNY-_Qd=W3dz24nw2u2+nML+B_4Oemail@example.com>
- References: <CAOvn4qgzAL3bcu=0qD+8inuZuqwQf7HuCA70XK50VqkbgSWJmw@mail.gmail.com> <20120324105912.GA1821@jwilk.net> <CAOvn4qjJz5EiuAXt=N85bHbh04XN2+T_Yvp6h8qKi5OmtXmRig@mail.gmail.com> <20120328201010.GA1064@jwilk.net> <CAOvn4qie-yBr-novh71RXNY-_Qd=W3dz24nw2u2+nML+B_4Ofirstname.lastname@example.org>
* Thomas Kluyver <email@example.com>, 2012-03-28, 22:33:
As far as I can see, the zoneinfo subpackage is used as a fallback by
dateutil.tz.gettz() if it can't find the equivalent system timezone
data files (the binary package has a dependency on tzdata).
zoneinfo.gettz() appears to account for the possibility that its local
data file doesn't exist, and returns None. I'm inclined to leave this
behaviour intact in case code depends on it, although it's not how I'd
design it myself. I've added a note in README.Debian pointing people to
Wouldn't it be better to update zoneinfo.gettz() tests to use
tz.gettz(), instead of disabling them entirely?
Please add get-orig-source target.
The copyright file mentions dateutil/zoneinfo/zoneinfo-2011d.tar.gz,
which doesn't exist in .orig.tar anymore.