Test dzone.008.ctst broken by tzdata-2022g

[vcunat]

It worked with tzdata-2022f.

FAIL: dzone.008
===============

$ dzone --prev Asia/Singapore 2014-02-22
--- "expected output  6394954b" 2022-12-10 09:49:37.048324670 +0000
+++ "actual output  6394954b"   2022-12-10 09:49:37.048324670 +0000
@@ -1 +1 @@
-1982-01-01T00:00:00+07:30 <- 1982-01-01T00:30:00+08:00 Asia/Singapore
+1981-12-31T23:30:00+07:30 <- 1982-01-01T00:00:00+08:00 Asia/Singapore
$? 1
FAIL dzone.008.ctst (exit status: 1)

============================================================================
Testsuite summary for dateutils 0.4.10
============================================================================
# TOTAL: 886
# PASS:  885
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================

Announcement seems related:

 Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time),
 not 24:00 local time.  (Thanks to Geoff Clare via Robert Elz.)

[hroptatyr]

Hi Vladimír,
thanks for bringing this to my attention. Fix is in 841c635, I shall only support the more recent, correct transition.

[hroptatyr]

Oh, had to back up here, the CI services need a test suite run without failure in order to produce artefacts (like tarballs and releases).

[mattdm]

Hmmm. This is a one-way gate: the old test will pass with tzdata-2022f and fail with tzdata-2022g; the new test will pass with tzdata-2022g and fail with tzdata-2022f.

[hroptatyr]

Yea, I noticed. The test has been replaced by querying Indonesia (similar history (shifting by half an hour) just 20 years prior).