-
Notifications
You must be signed in to change notification settings - Fork 7
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
TimeZoneSeries may produce overlapping LocalTime intervals #19
Comments
@olafklinke Yes, that use case is definitely in scope. This library explicitly supports series whose local time intervals overlap or have gaps. See the comments in the source code for a detailed explanation of the algorithm we use to support those, and a proof of its correctness. The type signature of I agree with you that it would be great to provide a variant with the more semantically correct (but non-backwards-compatible) return type of |
I was trying to define an invariant for |
Please update your invariant as noted in that issue, and let me know how it goes. |
Is the following invariant desired? Fix a Below is code demonstrating that this invariant does not hold for timezone-series-0.1.13.
|
One of the potential use cases for
TimeZoneSeries
is daylight savings time (DST). (related to another issue: infinite lists of time zone changes?) While the UTC time intervals of DST and non-DST do not overlap, their mapping toZonedTime
and then toLocalTime
will produce overlaps. This entails thatlocalTimeToUTC'
has more than one candidateUTCTime
for aLocalTime
inside the overlap. Moreover, someLocalTime
values should actually be illegal for a DST/non-DSTTimeZoneSeries
object, because clocks jump forward. By the use oflistToMaybe
insidelocalTimeToUTC'
the function currently disregards any extra candidates and by the use offromMaybe
it accepts illegal time stamps.So either the return type of
localTimeToUTC'
is changed to[UTCTime]
or we provide heuristics to guess the correctTimeZone
from context. I actually implemented the latter, but haven't published yet. The use case is series ofLocalTime
stamps that are known to be ascending inUTCTime
and belong to a knownTimeZoneSeries
. These are common. As a data scientist I deal with such time series every day. Question is whether handling of such series is within the scope of this package.The text was updated successfully, but these errors were encountered: