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

Time Zones do not Account for DST #15

Open
jrstrunk opened this issue Mar 26, 2024 · 3 comments
Open

Time Zones do not Account for DST #15

jrstrunk opened this issue Mar 26, 2024 · 3 comments

Comments

@jrstrunk
Copy link

jrstrunk commented Mar 26, 2024

The following code

birl.from_unix(1_711_456_116) |> birl.set_timezone("America/New_York") |> birl.to_iso8601 |> io.debug

produces 2024-03-26T07:28:36.000-05:00 when it should produce 2024-03-26T08:28:36.000-04:00 because America/New_York is in EDT time right now, which has the offset of -04:00. Between sometime in March and sometime in November each year in America the timezone offset values changes to an hour ahead because of Daylight Saving Time.

@jrstrunk
Copy link
Author

jrstrunk commented Mar 27, 2024

In the meantime I have adjusted my database to store formatted local time instead of timestamps so that I just don't have to worry about converting between them. I was able to do this comfortably because my project is tied to a local physical location, so data always originates from and is consumed in the same timezone.

Birl being Gleam native is really nice, but with the complexity of time zones, maybe it does not make sense for Birl to support them when the ecosystem project is still so new (I'm talking about named time zones, like "America/New_York", not offset times). Maybe a package should be created that is wrapper for an Erlang lib that handles getting the offset from named time zones, then it could be used with Birl once the proper offset is known.

@massivefermion
Copy link
Owner

yeah, I've been trying to solve this issue for a while, but I just couldn't find enough free time to do it.
Your suggestion makes sense, though I just don't think removing part of the functionality is the right thing to do here.
I think it makes more sense to just warn the users that this problem exists so that if a user determines that this issue won't affect them, they can still use the feature.
Thanks for the issue

@jrstrunk
Copy link
Author

jrstrunk commented May 1, 2024

Yeah now that the package is v1, I agree we can't just remove it. Maybe adding gleam's deprecated attribute to it would do the trick.

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

No branches or pull requests

2 participants