TZ with past DST but without future are denying has_dst_changes

[n1vux]

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]

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]

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.