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

Resolve ambiguity for permanent timezone changes #155

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

eugeneius
Copy link

Biz::Time already passes true as the dst parameter to local_to_utc to avoid the ambiguity of converting a local time that occurred twice due to daylight savings time.

However if a local time occurs twice due to a permanent timezone change, the dst parameter doesn't help. local_to_utc can be given a block to handle this case:

https://github.com/tzinfo/tzinfo/blob/v2.0.6/lib/tzinfo/timezone.rb#L613-L619

The dst parameter will not be able to resolve an ambiguity resulting from the clocks being set back without changing from daylight savings time to standard time. In this case, if a block is specified, it will be called to resolve the ambiguity. The block must take a single parameter - an Array of {TimezonePeriod}s that need to be resolved. The block can select and return a single {TimezonePeriod} or return nil or an empty Array to cause an {AmbiguousTime} exception to be raised.

I encountered this problem due to a recent timezone change in Kazakhstan:
https://mm.icann.org/pipermail/tz-announce/2024-February/000081.html

I used an older example in the test so that it doesn't require the latest tz database.

`Biz::Time` already passes true as the `dst` parameter to `local_to_utc`
to avoid the ambiguity of converting a local time that occurred twice
due to daylight savings time.

However if a local time occurs twice due to a permanent timezone change,
the `dst` parameter doesn't help. `local_to_utc` can be given a block to
handle this case:

https://github.com/tzinfo/tzinfo/blob/v2.0.6/lib/tzinfo/timezone.rb#L613-L619

> The `dst` parameter will not be able to resolve an ambiguity resulting
> from the clocks being set back without changing from daylight savings
> time to standard time. In this case, if a block is specified, it will
> be called to resolve the ambiguity. The block must take a single
> parameter - an `Array` of {TimezonePeriod}s that need to be resolved.
> The block can select and return a single {TimezonePeriod} or return
> `nil` or an empty `Array` to cause an {AmbiguousTime} exception to be
> raised.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant