On Sun, 22 Dec 2024 10:28:38 +0100, Lucas Nussbaum wrote: > > # Failed test 'Expected time for PST8PDT ( Ref: Sun Nov 1 00:55:00 2009, > > Calc: Sun Nov 1 01:00:00 2009' > > # at t/dst_back.t line 43. > > # got: '1257066000' > > # expected: '1257062400' > > # Looks like you failed 1 test of 3. > > t/dst_back.t ................... > > 1..3 > > ok 1 - Timezone MET not available > > ok 2 - Expected time for Europe/Berlin ( Ref: Sun Oct 25 02:55:00 2009, > > Calc: Sun Oct 25 03:00:00 2009 > > not ok 3 - Expected time for PST8PDT ( Ref: Sun Nov 1 00:55:00 2009, Calc: > > Sun Nov 1 01:00:00 2009 > > Dubious, test returned 1 (wstat 256, 0x100) > > Failed 1/3 subtests
> > Test Summary Report
> > -------------------
> > t/dst_back.t (Wstat: 256 (exited 1) Tests: 3 Failed: 1)
> > Failed test: 3
> > Non-zero exit status: 1
> > Files=16, Tests=108, 42 wallclock secs ( 0.06 usr 0.03 sys + 1.68 cusr
> > 0.32 csys = 2.09 CPU)
> > Result: FAIL
> > Failed 1/16 test programs. 1/108 subtests failed.
> > make[2]: *** [Makefile:835: test_dynamic] Error 255
> > make[2]: Leaving directory '/<<PKGBUILDDIR>>'
> > dh_auto_test: error: make -j8 test TEST_VERBOSE=1 "TEST_FILES=t/after_job.t
> > t/callbackreschedule.t t/delete_entry.t t/dst_back.t t/entry.t
> > t/execution_time.t t/load_crontab.t t/nofork.t t/pod.t t/pod_coverage.t
> > t/pretty_print_args.t t/process_name.t t/same_time_with_reschedule.t
> > t/sighandler.t t/startup.t t/timeshift.t" returned exit code 2
Interesting.
The background for this test is in the POD/manpage:
DST ISSUES
Daylight saving occurs typically twice a year: In the first switch,
one hour is skipped. Any job which triggers in this skipped hour
will be fired in the next hour. So, when the DST switch goes from
2:00 to 3:00 a job which is scheduled for 2:43 will be executed at
3:43.
For the reverse backwards switch later in the year, the behavior
is undefined. Two possible behaviors can occur: For jobs triggered
in short intervals, where the next execution time would fire in the
extra hour as well, the job could be executed again or skipped in
this extra hour. Currently, running "Schedule::Cron" in "MET" would
skip the extra job, in "PST8PDT" it would execute a second time.
The reason is the way how Time::ParseDate calculates epoch times
for dates given like "02:50:00 2009/10/25". Should it return the
seconds since 1970 for this time happening 'first', or for this
time in the extra hour ? As it turns out, Time::ParseDate returns
the epoch time of the first occurrence for "PST8PDT" and for "MET"
it returns the second occurrence. Unfortunately, there is no way to
specify which entry Time::ParseDate should pick (until now). Of
course, after all, this is obviously not Time::ParseDate's fault,
since a simple date specification within the DST back-switch period
is ambiguous. However, it would be nice if the parsing behavior of
Time::ParseDate would be consistent across time zones (a ticket has
be raised for fixing this). Then Schedule::Cron's behavior within a
DST backward switch would be consistent as well.
Since changing the internal algorithm which worked now for
over ten years would be too risky and I don't see any simple
solution for this right now, it is likely that this undefined
behavior will exist for some time. Maybe some hero is coming along
and will fix this, but this is probably not me ;-)
Sorry for that.
What makes this interesting is that the test failure happens for
Lucas and in the same way on ci.debian.net.
On reproducible-builds.org and locally the tests pass:
t/dst_back.t ...................
1..3
ok 1 - Timezone MET not available
ok 2 - Timezone Europe/Berlin not available
ok 3 - Expected time for PST8PDT ( Ref: Sun Nov 1 01:55:00 2009, Calc: Sun Nov
1 01:00:00 2009
ok
Smells like tzdata{,-legacy} maybe?
And indeed, if a add tzdata to B-D-I, I get the same test failure.
If I add both tzdata and tzdata-legacy, it passes again.
Somehow this looks like different build environments … and making
them consistent by requiring both packages, and thereby enabling all
3 subtests, doesn't sound obviously wrong, so I'm doing this now.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
signature.asc
Description: Digital Signature
