TZ with past DST but without future are denying has_dst_changes

n1vux commented 3 years ago

Antarctica/Casey is currently DST-free but has (very) historic DST until earlier this month.

The generated module has

sub has_dst_changes {0}

That should be a 1 despite current TZ span end of Inf as it has the historic outrageous ±3 hours twice-annual sleep-cycle disruptions (ouch) listed for prior years. (Pod says current, future, or historic.)

@autarch guesses this is a generator code issue.

n1vux commented 3 years ago

Also, since Antarctica/Casey has had DST in living memory, it should have a last_observance member? it lacks both that and rules

Test case with DT-TZ 2.43 (2020d)-

$ TZ='Antarctica/Casey' perl -MDateTime::TimeZone -MDateTime -MData::Dump=pp -E 'my $tz = DateTime::TimeZone->new(name=>q(local)); say $tz->has_dst_changes; say pp keys $tz->%*; say pp $tz' | less
0
("is_olson", "max_year", "spans", "name")
bless({
  is_olson => 1,
  max_year => 2030,
  name => "Antarctica/Casey",
  spans => [
    [-Inf, 62104147200, -Inf, 62104147200, 0, 0, "-00"],
...
    [
      63719280000,
      63737424060,
      63719308800,
      63737452860,
      28800,
      0,
      "+08",
    ],
    [63737424060, Inf, 63737463660, Inf, 39600, 0, "+11"],
  ],
}, "DateTime::TimeZone::Antarctica::Casey")

autarch commented 2 months ago

Actually, I just took a look and I don't think this is a bug. Here's the data for Antarctica/Casey from the 2024a IANA DB:

# Zone  NAME        STDOFF  RULES   FORMAT  [UNTIL]
Zone Antarctica/Casey    0  -   -00 1969
             8:00   -   +08 2009 Oct 18  2:00
            11:00   -   +11 2010 Mar  5  2:00
             8:00   -   +08 2011 Oct 28  2:00
            11:00   -   +11 2012 Feb 21 17:00u
             8:00   -   +08 2016 Oct 22
            11:00   -   +11 2018 Mar 11  4:00
             8:00   -   +08 2018 Oct  7  4:00
            11:00   -   +11 2019 Mar 17  3:00
             8:00   -   +08 2019 Oct  4  3:00
            11:00   -   +11 2020 Mar  8  3:00
             8:00   -   +08 2020 Oct  4  0:01
            11:00   -   +11 2021 Mar 14  0:00
             8:00   -   +08 2021 Oct  3  0:01
            11:00   -   +11 2022 Mar 13  0:00
             8:00   -   +08 2022 Oct  2  0:01
            11:00   -   +11 2023 Mar  9  3:00
             8:00   -   +08

The second column, STDOFF, is the offset from standard time, and it's never set, so this zone has never had DST. It's had a bunch of other changes, but apparently the database doesn't think these are DST changes.

houseabsolute / DateTime-TimeZone

TZ with past DST but without future are denying has_dst_changes #44