Consider removing timezones in tests that rely on `tzdata-legacy`

[richlander]

I tried adding a test leg for Ubuntu 24.10 in #110476. It failed due to UCT not being found. I didn't even know what UCT was! I do now, it's just another timezone alias.

runtime/src/libraries/System.Runtime/tests/System/TimeZoneInfoTests.cs

Line 2345 in 2b09eb6

"UCT",

This is due to: https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890#p-99950-tzdata-package-split

Related:

• https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
• Could not find file '/usr/share/zoneinfo/Europe/Kiev'. dotnet-docker#6072

I propose that we change our tests to only rely on time zones in tzdata. tzdata-legacy seems like an OS compat shim that we have no responsibility to test while we do have a responsibility to validate correct behavior when only tzdata is installed.

This is also evidence that we never integrated 24.04 into our CI. tzdata-legacy is not installed in our test image for that version: https://github.com/dotnet/dotnet-buildtools-prereqs-docker/blob/98df6254f2637235a711add92d17286e8c44fd59/src/ubuntu/24.04/helix/Dockerfile#L59.

What I observed:

root@142a317ad02d:/# cat /etc/os-release | head -n 1
PRETTY_NAME="Ubuntu 24.10"
root@142a317ad02d:/# apt update && apt install -y tzdata
root@142a317ad02d:/# ls /usr/share/zoneinfo/
Africa      Australia  Etc      MET      WET                tzdata.zi
America     CET        Europe   MST      iso3166.tab        zone.tab
Antarctica  CST6CDT    Factory  MST7MDT  leap-seconds.list  zone1970.tab
Arctic      EET        GMT      PST8PDT  leapseconds        zonenow.tab
Asia        EST        HST      Pacific  localtime
Atlantic    EST5EDT    Indian   UTC      posixrules
root@142a317ad02d:/# apt install -y tzdata-legacy
Installing:                     
  tzdata-legacy
root@142a317ad02d:/# ls /usr/share/zoneinfo/
Africa      Cuba     GMT+0      Kwajalein  Poland     Zulu
America     EET      GMT-0      Libya      Portugal   iso3166.tab
Antarctica  EST      GMT0       MET        ROC        leap-seconds.list
Arctic      EST5EDT  Greenwich  MST        ROK        leapseconds
Asia        Egypt    HST        MST7MDT    Singapore  localtime
Atlantic    Eire     Hongkong   Mexico     Turkey     posixrules
Australia   Etc      Iceland    NZ         UCT        right
Brazil      Europe   Indian     NZ-CHAT    US         tzdata.zi
CET         Factory  Iran       Navajo     UTC        zone.tab
CST6CDT     GB       Israel     PRC        Universal  zone1970.tab
Canada      GB-Eire  Jamaica    PST8PDT    W-SU       zonenow.tab
Chile       GMT      Japan      Pacific    WET

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-datetime
See info in area-owners.md if you want to be subscribed.

[richlander]

An alternative in the near-term is to install tzdata-legacy. That would be fine.

The whole purpose of testing the non-LTS Ubuntu version is to ensure we're on a good path to support. As a result, this is really a proposal for what we should do for .NET 10+ for Ubuntu 24.04+.

[Clockwork-Muse]

I propose that we change our tests to only rely on time zones in tzdata. tzdata-legacy seems like an OS compat shim that we have no responsibility to test while we do have a responsibility to validate correct behavior when only tzdata is installed.

Alternatively, create a limited set of curated timezone data, and use that instead (or see if there's an existing published test set). Timezone data is brittle and not stable, and we're relying on it to not change. We're quite likely to experience failures in the near term;

• The US Pacific states have been trying to move off DST for the last several years (in either direction).
• The EU has approved some changes around how countries are allowed to handle DST, so potential for rules for individual EU countries to change exists.

By using a stable dataset, we can avoid this problem.

[tarekgh]

Alternatively, create a limited set of curated timezone data, and use that instead (or see if there's an existing published test set). Timezone data is brittle and not stable, and we're relying on it to not change. We're quite likely to experience failures in the near term

We need to test with the original distro set. This is better to catch any change that could need some action from the .NET side. We caught some cases before that. Testing with fixed set will not be effective test as it will not catch anything I guess.

[richlander]

I think that our tests should be oriented on finding real customer issues. If we'd been testing Ubuntu 24.04 earlier, we would have found these failures before our users did.

Note, we'll see this same change in Debian next year.

Debian 12:

rich@mazama:~$ docker run --rm -it debian:bookworm ls /usr/share/zoneinfo
Africa	    Cuba     GMT+0	Kwajalein  Poland     Zulu
America     EET      GMT-0	Libya	   Portugal   iso3166.tab
Antarctica  EST      GMT0	MET	   ROC	      leap-seconds.list
Arctic	    EST5EDT  Greenwich	MST	   ROK	      leapseconds
Asia	    Egypt    HST	MST7MDT    Singapore  localtime
Atlantic    Eire     Hongkong	Mexico	   Turkey     posix
Australia   Etc      Iceland	NZ	   UCT	      posixrules
Brazil	    Europe   Indian	NZ-CHAT    US	      right
CET	    Factory  Iran	Navajo	   UTC	      tzdata.zi
CST6CDT     GB	     Israel	PRC	   Universal  zone.tab
Canada	    GB-Eire  Jamaica	PST8PDT    W-SU       zone1970.tab
Chile	    GMT      Japan	Pacific    WET

Debian 13:

rich@mazama:~$ docker run --rm -it debian:trixie ls /usr/share/zoneinfo
Africa	    Asia       Europe	Pacific		   leapseconds	zone.tab
America     Atlantic   Factory	UTC		   localtime	zone1970.tab
Antarctica  Australia  GMT	iso3166.tab	   posixrules	zonenow.tab
Arctic	    Etc        Indian	leap-seconds.list  tzdata.zi