1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • "Missing" entries in timezone tables

    From Alastair McKinstry@21:1/5 to All on Tue Apr 8 08:00:01 2025
    Hi,

    I have an issue with some missing entries in the zoneinfo files in
    tzdata that I need to resolve.

    I maintain two packages, python-pytz and python-xarray.

    python-tz provides a python interface to timezone data;in Debian its
    patched to read from zoneinfo rather tha ship its own copy of the data.

    python-xarray has in 2025.03.1 now got a unit test that fails because "US/Pacific" is not present.

    Now in python-tz 2025.2  it has changed its build procedure
    dramatically; the top-level Makefile pulls down zoneinfo via rsync (ugh)
    in build and edits it. In -1 I bypass this as we still apply our patch
    to use the official zoneinfo.

    But ./gen_tzinfo.py in python-tz adds extra timezones it believes should
    be present, including some backwards-compatible entries such as
    "US/Pacific". Adding these timezones is possible, but I am loath to
    diverge from tzdata..

    Any opinions or recommendations?

    Regards

    Alastair

    --
    Alastair McKinstry,
    GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
    e: mckinstry@debian.org, im: @alastair:mckinstry.ie https://mastodon.ie/@amckinstry

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ananthu C V@21:1/5 to All on Tue Apr 8 09:20:01 2025
    ------KYYIB6P6PECKJT7RL2HGZASVSR1USI
    Content-Type: text/plain;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    Hi,

    I am not entirely sure, but I think you can probably find those missing timezones in tzdata-legacy package.

    Best,
    Ananthu
    ------KYYIB6P6PECKJT7RL2HGZASVSR1USI
    Content-Type: text/html;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <!DOCTYPE html><html><body><div dir="auto">Hi,<br><br>I am not entirely sure, but I think you can probably find those missing timezones in tzdata-legacy package.<br><br>Best,<br>Ananthu</div></body></html>
    ------KYYIB6P6PECKJT7RL2HGZASVSR1USI--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Stone@21:1/5 to Alastair McKinstry on Tue Apr 8 18:20:01 2025
    On Tue, Apr 08, 2025 at 06:42:43AM +0100, Alastair McKinstry wrote:
    But ./gen_tzinfo.py in python-tz adds extra timezones it believes
    should be present, including some backwards-compatible entries such as >"US/Pacific". Adding these timezones is possible, but I am loath to
    diverge from tzdata..

    Any opinions or recommendations?

    I'd just depend on tzdata-legacy. I don't really understand why it was
    decided to put some names in a separate package, but it's a small one
    and if you need compatibility, that's what you need to do.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Stone@21:1/5 to Richard Laager on Tue Apr 8 19:40:01 2025
    On Tue, Apr 08, 2025 at 12:08:05PM -0500, Richard Laager wrote:
    I got bit (not in pytz) by US/Pacific disappearing, so I understand
    the annoyance from the user perspective. However, as that is what has >happening in tzdata, I don't think we should have individual packages
    trying to fight that individually/haphazardly.

    If you're maintaining a package that itself is trying to maintain compatibility, what else would you do? As the NEWS related to
    tzdata-legacy itself says:

    Please install tzdata-legacy in case you need the legacy timezones or to
    restore the previous behavior. This might be needed in case the system
    provides timezone-aware data over the network (e. g. SQL databases).

    If you patch US/Pacific back in manually, then you have two problems:

    1. Things are inconsistent. For example, US/Pacific works in Python,
    but not in systemd. (I realize that's the state that upstream pytz is >creating already, but you needn't follow them down this road.)

    Why would it not work in systemd? I'd argue that any inconsistency would
    be to have debian's pytz needlessly diverge from its expected functionality.

    2. You will never know when it's acceptable to remove these, so you'll
    feel stuck carrying that forever. (On the other hand, you are just
    following upstream pytz, so you can say it's their problem. But, they
    will definitely have this same problem of not knowing when to remove
    the backwards compatibility.)

    Yeah, that's how backward compatibility works. I don't see the problem
    at the cost of a few symlinks.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Stone@21:1/5 to Richard Laager on Wed Apr 9 00:30:01 2025
    On Tue, Apr 08, 2025 at 04:50:58PM -0500, Richard Laager wrote:
    Option C would also keep the whole system consistent. But in that
    scenario, installing python-tz indirectly adds system-wide timezone
    values. I'm hesitant about that idea; it feels like "spooky action at
    a distance".

    FWIW, that's how I feel about stuff that worked literally for decades up
    and disappearing for no apparent reason, but that's neither here nor there.

    As a sysadmin, I could see that leading me to
    troubleshoot, "Why does this systemd timer that uses US/Pacific work
    on system A, but not system B?" or "Why does `TZ=US/Pacific date` work
    on some terminals and not others?" The answer, "Because system A
    installed software P that depends on python-tz, so that pulled in >tzdata-legacy.", would feel surprising once I found it. This is
    heavily my personal opinion, though.

    It's IMO much easier to understand this outcome in a debian context as
    dpkg -S US/Pacific
    will clarify things pretty quickly.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)