Fedora Account System
Red Hat Associate
Red Hat Customer
This bug was initially created as a copy of Bug #2341179 I am copying this bug because: The test failure noted in https://bugzilla.redhat.com/show_bug.cgi?id=2341179#c4 shows that CET is 18 minutes away from UTC instead of some round hour: E [left]: [1999-12-31T23:42:00.000000000, 2000-12-31T23:42:00.000000000] E [right]: [1999-12-31T23:00:00.000000000, 2000-12-31T23:00:00.000000000] python-pandas failed to build from source in Fedora rawhide/f42 https://koji.fedoraproject.org/koji/taskinfo?taskID=128086171
I'm not seeing this when using tzdata with date: $ cat /etc/fedora-release Fedora release 42 (Adams) $ rpm -qa | grep tzdata tzdata-2025b-1.fc42.noarch $ TZ=CET date; TZ=UTC date Wed Aug 20 05:05:09 PM CEST 2025 Wed Aug 20 03:05:09 PM UTC 2025 However, this change to tzdata may be related: Names present only for compatibility with UNIX System V (last released in the 1990s) have been moved to 'backward'. These names, which for post-1970 timestamps mostly just duplicate data of geographical names, were confusing downstream uses. Names moved to 'backward' are now links to geographical names. This affects behavior for TZ='EET' for some pre-1981 timestamps, for TZ='CET' for some pre-1947 timestamps, and for TZ='WET' for some pre-1996 timestamps. Also, TZ='MET' now behaves like TZ='CET' and so uses the abbreviation "CET" rather than "MET". Those needing the previous TZDB behavior, which does not match any real-world clocks, can find the old entries in 'backzone'. It looks like pandas uses pytz with CET, possibly in an unsupported way. . From the pytz docs: Unfortunately using the tzinfo argument of the standard datetime constructors ‘’does not work’’ with pytz for many timezones. ... It is safe for timezones without daylight saving transitions though, such as UTC: This upstream commit may resolve the test failure but I have not tested it. https://github.com/pandas-dev/pandas/commit/1cf98aa9ecd65764ace8f0e38cf54220f3034052