Calendar time zone provider#959
Open
maknapp wants to merge 9 commits into
Open
Conversation
Implements Nodatime's IDateTimeZoneProvider for Calendar using its VTIMEZONE components.
Evaluate events in custom time zone
This also stops caching the system time zone, which should not have been happening anyway because the system time zone can change.
Adds a case-insensitive time zone provider to more closely match previous behavior.
Events within a calendar can be evaluated in parallel, which would make multiple threads access TimeZoneProvider at the same time.
|
Codecov Report❌ Patch coverage is ❌ Your patch check has failed because the patch coverage (72.3%) is below the target coverage (80.0%). You can increase the patch coverage or adjust the target coverage. @@ Coverage Diff @@
## main #959 +/- ##
=======================================
+ Coverage 71.5% 71.9% +0.5%
=======================================
Files 118 116 -2
Lines 4585 4698 +113
Branches 1068 1082 +14
=======================================
+ Hits 3277 3379 +102
- Misses 955 963 +8
- Partials 353 356 +3
... and 2 files with indirect coverage changes 🚀 New features to boost your workflow:
|
Collaborator
|
That sounds pretty nice. I'll need some time to go through changes. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.


This adds a
Calendar.TimeZoneProviderproperty to allow users to specify theNodaTime.IDateTimeZoneProviderto use during calendar/event evaluation. The default time zone provider for a calendar isCalendarTimeZoneProviders.TzdbWithAliaseswith the calendar defined time zones as the fallback. The default time zone provider for components without a calendar parent isCalendarTimeZoneProviders.TzdbWithAliases.User choice
Users can choose the time zone provider:
CalendarTimeZoneProviders.Combine()to create their ownNodaTime.IDateTimeZoneProviderthat searches the specified providers in the given order for a matching time zoneNodaTime'sDateTimeZoneProviders.Tzdbdirectly - with or without the calendar's VTIMEZONE componentscal.TimeZoneProvider = cal.CreateTimeZoneProvider())VTIMEZONE
VTIMEZONE changes are not automatically handled. VTIMEZONE components are converted to
NodaTime.DateTimeZonevalues on demand and cached. If a VTIMEZONE component is added/removed/changed AFTER being used by the time zone provider, theCalendar.TimeZoneProviderwill need to be recreated to be up-to-date with the calendar VTIMEZONE components.One (unlikely?) issue users might run into is that
NodaTime.ZonedDateTimechecks equality byReferenceEqualsof itsDateTimeZone, so recreating theCalendar.TimeZoneProvidercould cause issues if the user tries to compare aZonedDateTimewith another created from a different time zone provider because they would have two differentDateTimeZoneobjects even though they represent the same VTIMEZONE.Exceptions
Missing time zone errors will now throw NodaTime's DateTimeZoneNotFoundException instead of ArgumentException. I'm not sure if there are downsides vs catching and rethrowing with our own
TimeZoneNotFoundException. I do like having a more specific exception instead ofArgumentException. Related #648.No more time zone exceptions in Calendar.Load(). As stated above, exceptions due to missing time zones are now thrown during evaluation.
Time zone searching
The
Calendar.TimeZoneProvideris created on demand with a default value if none is specifically set. The default is NOT an exact copy of the previousTimeZoneResolver. Since this brings more time zone control to the user, it seemed reasonable to remove the more non-standard searching by default: case-insensitive andstring.Containssearching. I did add a case-insensitive time zone provider in case that is actually needed - I would like to remove that commit though unless users actually need it. I ignored adding astring.Containsreplacement because that seems very inaccurate to me.Searching
XmlSerializationSettingswas also removed completely because it is, by NodaTime default, just the TZDB. What is the purpose of searchingNodaTime.Xml.XmlSerializationSettings.DateTimeZoneProvider? The user can add this provider if they actually use this, so I think it is safe to ignore it completely.Global time zone handling removed
DefaultTimeZoneResolverandTimeZoneResolverswere removed. Having a default time zone provider on the calendar is essentially the same thing for users who currently ignore time zones.CalDateTime
This now requires a time zone provider to convert to a
ZonedDateTime. @axunonb mentioned in #749 that there should be a resolver-less overload still, but a user converting to aZonedDateTimeshould always be paying attention to the time zone provider anyway. If a user really wants to ignore it, they can just use extensions to use a default time zone provider.ToDateTimeUtc()is also removed just because I did not want to require aNodaTimetime zone provider to create aDateTime. Users avoidingNodaTimecan still useToDateTimeUnspecified()to get just the local time. Users can also use extensions to create aToDateTimeUtc()however they want.None of these changes are breaking changes for
CalDateTimebecause they are not in v5.Fixes #749