I wonder how this library deals with ambiguous times around daylight savings. For example on the day of switching from summertime to wintertime the clock goes from 2:59 am to 2:00 am again resulting in the hour being repeated. If you know the correct time zone for that timestamp, it is still ambiguous which of the two UTC times it maps to.
I've always wondered how the world in general can tolerate something like that. Here we are adding leap _seconds_ every year or so, and yet we're all totally fine with the same, indistinguishable hour repeating once a year.
We (Bloomberg) have a very nice C++ library designed on top of the IANA timezone data that will hopefully make its way to GitHub eventually. The API for that library allows the caller to specify either explicitly DST or STANDARD or an UNSPECIFIED enum value which means the API will let you know whether the resulting conversion is ambiguous so that you can take correct action. This only comes up to bite you when you are storing datetimes in non-UTC timezones. If you simply store UTC there is no ambiguity when converting to a specific location's timezone.
Usually there is a separate timezone for daylight saving periods. For example where I live, there is a +9:30 timezone for half of the year, and a +10:30 timezone during daylight savings. This removes all the ambiquity, and allows the illlusion that UTC is a continuous stream.
