-
Notifications
You must be signed in to change notification settings - Fork 110
Disable tests for one more timezone #424
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
Conversation
da1e18d
to
92290e4
Compare
e4f894f
to
1d49eb1
Compare
bb66999
to
9f01dc0
Compare
Looks like Paraguay Standard Time is another strange one. The error message after all these manipulations is (formatted for convenience):
According to Windows, DST starts in 2025 on 2025-03-24 ± 1 day. Let's go through raw data manually.
See https://learn.microsoft.com/en-us/windows/win32/api/timezoneapi/ns-timezoneapi-time_zone_information for how to interpret the numbers. What I'm seeing is: March, the last occurrence of Saturday, 23:59:59.999. Finally,
No matter how you turn this, the last Saturday and Sunday are not the 24th, nor the 23rd. |
.toInstant(lastOffset) | ||
transitionEpochSeconds.add(newYearInLastOffset.epochSeconds) | ||
} | ||
offsets.add(recurring.offsetAtYearStart()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can it create a transition from an offset to the same offset if added unconditionally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but I can't think of a way to see the extra transitions using the API exposed to our users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, let's think about it if/when we're going to expose transition rules later
No description provided.