Skip to content

Resolve ambiguity for permanent timezone changes#155

Open
eugeneius wants to merge 1 commit into
zendesk:masterfrom
eugeneius:local_to_utc_block
Open

Resolve ambiguity for permanent timezone changes#155
eugeneius wants to merge 1 commit into
zendesk:masterfrom
eugeneius:local_to_utc_block

Conversation

@eugeneius

Copy link
Copy Markdown

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