I see the repo has advanced to the 0.2 series. But there are still libraries such as timezone-olson-th that depend on the 0.1.* series. I noticed that the 0.1.9 release works just fine with time<1.14 instead of its current time<1.10 bound. I am having a problem compiling with time 1.9 on GHC 9.2, so I would appreciate if this bound could be loosened. Thank you.

This library is having trouble parsing some timezone files from ArchLinux. I've attached an example. More details can be found at matterhorn-chat/matterhorn#542. I'm not sure if this is a duplicate of #7, though.

Sao_Paulo.zip

Data/Time/LocalTime/TimeZone/Olson/Types.hs:74:10: error:
    • No instance for (Semigroup OlsonData)
        arising from the superclasses of an instance declaration
    • In the instance declaration for ‘Monoid OlsonData’
   |
74 | instance Monoid OlsonData where
   |          ^^^^^^^^^^^^^^^^

See https://prime.haskell.org/wiki/Libraries/Proposals/SemigroupMonoid for details.

I have a TZif v2 file that looks like this:

00000000  54 5a 69 66 32 00 00 00  00 00 00 00 00 00 00 00  |TZif2...........|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 01 00 00 00 02  00 00 00 08 92 e6 92 48  |...............H|
00000030  01 ff ff fc 38 00 00 00  00 00 00 00 04 4c 4d 54  |....8........LMT|
00000040  00 47 4d 54 00 54 5a 69  66 32 00 00 00 00 00 00  |.GMT.TZif2......|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  01 00 00 00 02 00 00 00  |................|
00000070  08 ff ff ff ff 92 e6 92  48 01 ff ff fc 38 00 00  |........H....8..|
00000080  00 00 00 00 00 04 4c 4d  54 00 47 4d 54 00 0a 47  |......LMT.GMT..G|
00000090  4d 54 30 0a                                       |MT0.|

(/usr/share/zoneinfo/Africa/Abidjan from tzdata-2019b-1 on Arch Linux)

It's being parsed into the following OlsonData:

OlsonData {olsonTransitions = [Transition {transTime = -1830383032, transIndex = 1},Transition {transTime = -1830383032, transIndex = 1}], olsonTypes = [], olsonLeaps = [], olsonPosixTZ = Just "GMT0"}

Note that olsonTypes is empty while olsonTransitions references into it, this is obviously incorrect.

The source of the issue seems to be that the v1 header contains, in RFC8536 jargon, typecnt=2 but isutcnt=0 and isstdcnt=0. The RFC states:

standard/wall indicators: A series of one-octet values indicating
whether the transition times associated with local time types were
specified as standard time or wall-clock time. Each value MUST be
0 or 1. A value of one (1) indicates standard time. The value
MUST be set to one (1) if the corresponding UT/local indicator is
set to one (1). A value of zero (0) indicates wall time. The
number of values is specified by the "isstdcnt" field in the
header. If "isstdcnt" is zero (0), all transition times
associated with local time types are assumed to be specified as
wall time.

UT/local indicators: A series of one-octet values indicating whether
the transition times associated with local time types were
specified as UT or local time. Each value MUST be 0 or 1. A
value of one (1) indicates UT, and the corresponding standard/wall
indicator MUST also be set to one (1). A value of zero (0)
indicates local time. The number of values is specified by the
"isutcnt" field in the header. If "isutcnt" is zero (0), all
transition times associated with local time types are assumed to
be specified as local time.

Emphasized part is suggesting that the file above is valid, and should be interpreted as if all transitions happened in Wall time.

The related logic is implemented in https://github.com/ygale/timezone-olson/blob/master/Data/Time/LocalTime/TimeZone/Olson/Parse.hs#L152-L165 where zipWithExtend is used in case either the isstds or the isgmts is shorter than the other. However then regular zipWith is used to join the resulting list with the list of ttinfos.

Thus the case when both isstds and isgmts are shorter than ttinfos is not handled and we get a truncated list of types as above.

Various zone files (eg Etc/UTC) aren't handled on my system because they're using RFC 8536 and need 4ff152b. Would you be able to upload a new version to Hackage, please?

I ran this test program:

module Main where
import Data.Time
import Data.Time.LocalTime.TimeZone.Series
import Data.Time.LocalTime.TimeZone.Olson

main :: IO ()
main = do
    tzs <- getTimeZoneSeriesFromOlsonFile "/usr/share/zoneinfo/America/New_York"
    putStrLn $ show $ timeZoneFromSeries tzs $ UTCTime (fromGregorian 2038 7 1) 0

Result:

EST

By comparison, the C library correctly gives EDT:

$ env TZ=America/New_York date -d '2038-07-01 UTC'
Wed Jun 30 20:00:00 EDT 2038