-
Notifications
You must be signed in to change notification settings - Fork 18
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
Support converting between DateTime
and ZonedDateTime
interval types
#178
Comments
As moving between |
Our use case is that we need to work around JuliaTime/TimeZones.jl#271. Since we have large arrays of timestamp intervals with the same timezone we can just determine that timezone by sampling the file. Only parsing the datetime component is faster and more space efficient. To avoid breaking internally APIs we add the timezone back, only when queried. |
It would be great to find a path forward on that. As you're already working with switching to using struct UTCDateTime <: AbstractZonedDateTime
utc::DateTime
end This avoids having to implicitly keep track of the Finally, even with convert(AnchoredInterval{ZonedDateTime{TZ"America/New_York"}}, interval::AnchoredInterval{UTCDateTime})
convert(AnchoredInterval{UTCDateTime}, interval::AnchoredInterval{ZonedDateTime}) |
Yeah, that's the main reason why I didn't want to get into it. In this particular case, we don't really need a more general solution, and even the UTCDateTime solution would require more significant updates. I agree that in the future we'll probably want to go that direction, but for the couple hundred LOC in which we're tracking the timezone I don't think it's a priority. FWIW, I think these conversions should be supported regardless of whether the |
Fair enough. It helps seeing the bigger picture to figure out a better path forward.
The |
Yeah, that's what we're doing for now, just opened this issue more for reference. If we want to drop the |
Currently, if you want to convert an interval of
DateTime
s to aZonedDateTime
you need to do something like:I'm not sure if overloading the
DateTime
andZonedDateTime
constructors makes sense here, but these conversions should probably be handled in this package given that they're pretty common operations and we're already depending on TimeZones.jl.The text was updated successfully, but these errors were encountered: