Add timezone support to time intervals.
This PR addresses #2771 by adding a time_zone field to time interval definitions, which accepts an IANA time zone name (like 'Australia/Sydney') and if supplied means that the time intervals are defined inside that time zone.
On Windows machines the only time zones that are accepted are 'Local' and 'UTC', but I think that is probably enough for 99% of users who just want to use their local server time zone. I have noted this in the documentation, and also added some more info to the error message when a timezone fails to load on Windows mentioning that the user may need to supply their own time zone database.
I think it's also probably worth changing the default to be the server's local time rather than UTC as this would probably be unexpected for most users, but it is breaking behavior so I'm not sure how we should proceed with that but open to the ideas.
Feedback on the approach (particularly dealing with Windows) is more than welcome. Cheers!
It seems I've fixed the tests that were failing, but I'm not sure what's going wrong with the 'mixin' part of the CI pipeline, it looks unrelated to my changes...
@benridley looks like this was addressed in #2785 so a rebase on top of main should resolve this for you
Thanks @PhilipGough, I've just rebased so we'll see how it goes.
As discussed elsewhere, while "timezone" in the context of the TZ database indeed refers to a location (e.g. "Australia/Sydney"), the general understanding of "timezone" is more ambiguous. In many other contexts, a timezone is something like "PDT" or "PST" (or even "PST/PDT" :scream: ). As a concrete example particularly relevant for Go developers, look at the terminology in https://pkg.go.dev/time#Time .
Therefore, I suggest to use a word like "location". Even if you come from a TZ database context, you will still understand what that is, while those from other contexts will have a much easier life (not trying to enter "PDT" and wondering why it doesn't work).
Sure @beorn7, I think that's a good suggestion and keeps the terminology consistent with Go's stdlib. Happy to add this.
Great feedback from @beorn7 (as usual) on location vs. time zone, +1 for me.
Hey, wondering if this is still being worked on as we'd need this feature. Also assuming this works well with daylight saving?
Hey @piotr1212,
Yeah it's coming - I was mainly waiting on #2779 because I knew I'd need to rebase and fix this code up once that was merged. I'll probably work on it this weekend and get it tidied up.
And yes, it will work fine with daylight savings - Provided you aren't running AM on Windows.
I've just rebased onto main, and also added in the following:
- Renamed Timezone/time_zone to Location/location as its a more accurate description and consistent with Go's stdlib (thanks @beorn7)
- Added in @simonpasquier's suggestion to be more specific with the Windows error and check.
- Fixed up the docs to use the 'location' keyword, and also added some more details about what it does.
@simonpasquier could we go ahead and merge this please ?
Thanks for those test corrections @sylr, I've just merged them.