Fix/recurrence respect event timezone#1197
Open
kruggiero97 wants to merge 3 commits intoFossifyOrg:mainfrom
Open
Fix/recurrence respect event timezone#1197kruggiero97 wants to merge 3 commits intoFossifyOrg:mainfrom
kruggiero97 wants to merge 3 commits intoFossifyOrg:mainfrom
Conversation
addIntervalTime wasn't using the event's timeZone field at all, it was just defaulting to whatever zone the device was in. Once a recurring event crossed a DST boundary, every following occurrence drifted by an hour, i.e. an event created in ET but read in AST would display the right time before the DST transition and the wrong time after. The fix reads the event's timeZone, falls back to the device default if it's empty or Joda-Time doesn't recognize it, and passes the resolved zone into Formatter.getDateTimeFromTS. Joda already does DST math correctly. Closes FossifyOrg#165
Author
Test 1 Pacific Standard TimeCreated recurring event:
Test 2 West Europe Standard TimeCreated recurring event:
Test 3 Tokyo Standard TimeCreated recurring event:
Test 4 AUS Eastern Standard TimeCreated recurring event:
Test 5 Eastern Standard Time, Monthly RecurrenceCreated recurring event:
Test 6 Eastern Standard Time, Yearly RecurrenceCreated recurring event:
Verified across 6 source timezones (Pacific, Berlin, Tokyo, Sydney, Eastern monthly, Eastern yearly), 4 DST transitions (US spring-forward, EU spring-forward, Australia fall-back, none for Tokyo) |
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
1 participant
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.
Type of change(s)
What changed and why
Event.addIntervalTimenow uses the event's storedtimeZonefor recurrence math, falling back to the device default if it's empty or not recognized.addIntervalTimewasn't using the event'stimeZonefield at all, it was just defaulting to whatever zone the device was in. Once a recurring event crossed a DST boundary, every following occurrence drifted by an hour, i.e. an event created in ET but read in AST would display the right time before the DST transition and the wrong time after.Tests performed
Built debug APK, installed on a phone in
America/Puerto_Ricowhich doesn't observe DST. Verified against a real Outlook calendar synced to the device via the Outlook Android app.For each test, occurrences before and after the DST boundary were verified against expected local times in AST. Detailed observed vs expected values posted in a follow-up comment.
* Notes for tests 3 and 4:
While testing, I noticed that for events with non-local source timezones, the calendar view places each occurrence on the source-timezone date rather than the device-local date. This affected the displayed dates in tests 3 and 4 (times were correct, dates were off). Confirmed the same date behavior in release 1.10.3, seems to be unrelated to this PR.
May also address #506, #535, and possibly #71/#262, but I haven't verified against those reporters reproduction steps.
Closes the following issue(s)
Checklist
CHANGELOG.md(if applicable).