We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
HOURLY
Describe the bug teambition/rrule-go version: v1.8.2
We ran across an issue where RRULEs that use HOURLY intervals return incorrect timestamps when the timestamp corresponds to a DST switch.
Consider the following scenario:
Australia/Sydney
2022-10-02 02:00
AEST (+1000)
AEDT (+1100)
2022-10-02 01:00
2022-10-02 01:00:00 +1000 AEST
2022-10-01 15:00:00 +0000 UTC
2022-10-02 03:00:00 +1100 AEDT
2022-10-01 16:00:00 +0000 UTC
2022-10-02 04:00:00 +1100 AEDT
2022-10-01 17:00:00 +0000 UTC
The same bug can be seen when DST ends on April 2nd 2023.
To Reproduce We have raised a PR to show the bug.
Expected behavior Should return correct hour values.
The text was updated successfully, but these errors were encountered:
Bump
Sorry, something went wrong.
@zensh - When can we get the linked PR merged in? Thanks.
No branches or pull requests
Describe the bug
teambition/rrule-go version: v1.8.2
We ran across an issue where RRULEs that use
HOURLY
intervals return incorrect timestamps when the timestamp corresponds to a DST switch.Consider the following scenario:
Australia/Sydney
starts at2022-10-02 02:00
and the clocks go forward 1 hour. The timezone changes fromAEST (+1000)
toAEDT (+1100)
.2022-10-02 01:00
with a count of 3, should return the following values:2022-10-02 01:00:00 +1000 AEST
/2022-10-01 15:00:00 +0000 UTC
2022-10-02 03:00:00 +1100 AEDT
/2022-10-01 16:00:00 +0000 UTC
2022-10-02 04:00:00 +1100 AEDT
/2022-10-01 17:00:00 +0000 UTC
2022-10-02 01:00:00 +1000 AEST
/2022-10-01 15:00:00 +0000 UTC
2022-10-02 03:00:00 +1100 AEDT
/2022-10-01 16:00:00 +0000 UTC
2022-10-02 03:00:00 +1100 AEDT
/2022-10-01 16:00:00 +0000 UTC
The same bug can be seen when DST ends on April 2nd 2023.
To Reproduce
We have raised a PR to show the bug.
Expected behavior
Should return correct hour values.
The text was updated successfully, but these errors were encountered: