gdatetime test: Fix regression with tzdata 2024b
-
gdatetime test: Do not assume PST8PDT was always exactly -8/-7
From: Rebecca N. Palmer
In newer tzdata, it is an alias for America/Los_Angeles, which has a slightly different meaning: DST did not exist there before 1883. As a result, we can no longer hard-code the knowledge that interval 0 is standard time and interval 1 is summer time, and instead we need to look up the correct intervals from known timestamps.
Resolves: #3502 (closed)
Bug-Debian: https://bugs.debian.org/1084190
[smcv: expand commit message, fix whitespace] -
gdatetime test: Try to make PST8PDT test more obviously correct
Instead of using timestamp 0 as a magic number (in this case interpreted as 1970-01-01T00:00:00-08:00), calculate a timestamp from a recent year/month/day in winter, in this case 2024-01-01T00:00:00-08:00.
Similarly, instead of using a timestamp 15 million seconds later (1970-06-23T15:40:00-07:00), calculate a timestamp from a recent year/month/day in summer, in this case 2024-07-01T00:00:00-07:00.
-
gdatetime test: Fall back if legacy System V PST8PDT is not available
On recent versions of Debian, PST8PDT is part of the tzdata-legacy package, which is not always installed and might disappear in future. Successfully tested with and without tzdata-legacy on Debian unstable.