You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have an api like TimeZone -> LocalTime -> TimeZoneOffset
Have an api like LocalTime -> TimeZone -> [UTCTime] (because each local time could reference 0, 1, or more utc times) and UTCTime -> TimeZone -> LocalTime (all without IO)
The text was updated successfully, but these errors were encountered:
localTimeToUTC is nice, but how is a user supposed to know which TimeZone (offset) is supposed to be used?
This is important because getCurrentTimeZone is likely wrong, i.e. because the local time is more than a few months away from "right now".
So proper time-zone functionality is #89, to copy time-zone code from the timezone-series & timezone-olson packages. This would be time version 2.0.
Rename TimeZone to TimeZoneOffset
This may or may not be worth doing. It's certainly a regret of mine, see here.
There are also other issues with the current TimeZone type.
localTimeToUTC is nice, but how is a user supposed to know which TimeZone (offset) is supposed to be used?
Currently the time library only knows about the configured time-zone. But to get the time zone offset for some particular time, you can use getTimeZone.
It would be great to:
TimeZone
toTimeZoneOffset
TimeZone
TimeZone -> LocalTime -> TimeZoneOffset
LocalTime -> TimeZone -> [UTCTime]
(because each local time could reference 0, 1, or more utc times) andUTCTime -> TimeZone -> LocalTime
(all without IO)The text was updated successfully, but these errors were encountered: