Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TZ related failures in S32-temporal/local.t #3501

Open
p6rt opened this issue Sep 4, 2014 · 3 comments
Open

TZ related failures in S32-temporal/local.t #3501

p6rt opened this issue Sep 4, 2014 · 3 comments
Labels
RFC Request For Comments

Comments

@p6rt
Copy link

p6rt commented Sep 4, 2014

Migrated from rt.perl.org#122702 (status was 'open')

Searchable as RT122702$

@p6rt
Copy link
Author

p6rt commented Sep 4, 2014

From @coke

This test was historical run only if the system timezone was the same
as the test; recent updates force a value for $*TZ, but this causes
several test failures, with results like​:

not ok 25 - DateTime.local (from UTC, with leap second)

# Failed test 'DateTime.local (from UTC, with leap second)'
# at t/spec/S32-temporal/local.t line 1
# expected​: '1998-12-31T18​:59​:60-0500'
# got​: '1998-12-31T19​:59​:60-0400'

There are more tests that expect the -0500 than just the failing ones,
so this file needs some review.

For now, fudging the failing tests.

--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Sep 4, 2014

@coke - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Sep 10, 2014

From @carbin

On Thu Sep 04 10​:30​:12 2014, coke wrote​:

This test was historical run only if the system timezone was the same
as the test; recent updates force a value for $*TZ, but this causes
several test failures, with results like​:

not ok 25 - DateTime.local (from UTC, with leap second)

# Failed test 'DateTime.local (from UTC, with leap second)'
# at t/spec/S32-temporal/local.t line 1
# expected​: '1998-12-31T18​:59​:60-0500'
# got​: '1998-12-31T19​:59​:60-0400'

There are more tests that expect the -0500 than just the failing ones,
so this file needs some review.

For now, fudging the failing tests.

Are those tests actually supposed to pass? They seem to depend on knowing when the various timezones enter/leave DST, and when DST dates were modified.

For example​:

$dt = ds('1984-04-29T06​:55​:00Z').local;
is ~$dt, '1984-04-29T01​:55​:00-0500', 'DateTime.local (from UTC, just before DST begins)';

$dt = ds('1984-04-29T07​:02​:00Z').local;
is ~$dt, '1984-04-29T03​:02​:00-0400', 'DateTime.local (from UTC, just after DST begins)';

This expects that the implementation knows that DST started in America/New_York at 3​:00 on April 29 1984, and that at 1​:55 it was still in standard time, and that the date that .local produces will be adjusted accordingly, regardless of whether the system time is in DST or not when the test is run.

As another example,

DateTime.new("2014-02-28T06​:00​:00")
2014-02-28T06​:00​:00Z

DateTime.new("2014-02-28T06​:00​:00").local
2014-02-28T18​:00​:00+1200

If those tests are expected to pass that is wrong, as NZ was in DST (+1300) in February, even though I am running that in September and my timezone is not in DST and so is +1200, the result should be​:

DateTime.new("2014-02-28T06​:00​:00").local
2014-02-28T19​:00​:00+1300

I am not sure that it is supposed to work like that.

@p6rt p6rt added the RFC Request For Comments label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC Request For Comments
Projects
None yet
Development

No branches or pull requests

1 participant