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

How to get UTC Offset as integer #353

Open
bryaan opened this issue Jul 23, 2021 · 6 comments
Open

How to get UTC Offset as integer #353

bryaan opened this issue Jul 23, 2021 · 6 comments

Comments

@bryaan
Copy link

bryaan commented Jul 23, 2021

How can I get the current UTC offset from tz"America/New_York" ?

@omus
Copy link
Member

omus commented Jul 23, 2021

You can use access the offset of a specific ZonedDateTime via:

julia> using TimeZones

julia> now(tz"America/New_York").zone.offset
UTC-5/+1

julia> string(ans)
"-04:00"

If this is something you're just wanting to view for yourself you can do:

julia> show_next_transition(tz"America/New_York")
Transition Date:   2021-11-07
Local Time Change: 02:00  01:00 (Backward)
Offset Change:     UTC-5/+1  UTC-5/+0
Transition From:   2021-11-07T01:59:59.999-04:00 (EDT)
Transition To:     2021-11-07T01:00:00.000-05:00 (EST)

Which shows the current offset in "Offset Change" as well as a other information.

@bryaan
Copy link
Author

bryaan commented Jul 25, 2021

@omus Thank you! Can we add an int(timezoneawaretime) to make integer conversion easier?

@ericphanson
Copy link
Contributor

It would be nice to have something like

function get_offset_seconds(zdt)
    offset = FixedTimeZone(zdt).offset
    return offset.dst + offset.std
end

as part of the API. The issue with the string version is that it will show as eg "EDT":

julia> zdt1 = ZonedDateTime(2014, 5, 30, 21, tz"America/New_York")
2014-05-30T21:00:00-04:00

julia> string(FixedTimeZone(zdt1))
"EDT"

@omus
Copy link
Member

omus commented Dec 16, 2024

I do think we can support a nice way of extracting the offset information than we currently have. Some considerations we need to keep in mind:

  • We can't generally extract an offset from a time zone alone. This is possible for FixedTimeZone types but VariableTimeZones require an instance in time to determine what the offset would be. This means you would probably get the offset from a ZonedDateTime.
  • We would want to keep track of units so this function would likely output the type Second
  • The offsets are comprised of the standard offset and the daylight saving time offset. Most users will care about the sum of these values but this does mean we probably shouldn't use convert here as the conversion isn't lossless.

@langestefan
Copy link

langestefan commented Jan 1, 2025

Completely agree with above comments. This required some googling, and I ended up here. +1

The offsets are comprised of the standard offset and the daylight saving time offset.

If I understand correctly, the 'standard' offset would be referred to as the Meridian offset. For my specific application I need this value to compute the Local Standard Time Meridian.

@omus
Copy link
Member

omus commented Jan 13, 2025

The terminology used in TimeZones.jl is mainly based upon https://data.iana.org/time-zones/code/theory.html. In most cases uses want the standard offset and daylight saving offset added together.

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

4 participants