Data.Time.LocalTime.TimeZone is not a timezone but a timezone offset

[Tom Sydney Kerckhove]

It would be great to:

1. Rename TimeZone to TimeZoneOffset
2. Have a proper TimeZone
3. Have an api like TimeZone -> LocalTime -> TimeZoneOffset
4. 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)

[Tom Sydney Kerckhove]

To elaborate a bit:

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".

[Ashley Yakeley]

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.

[Ashley Yakeley]

Closing this as covered by #89.