🐛 Source Jira: fix timezone issue #48838
Merged
Conversation
This file contains 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
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Skipped Deployment
|
octavia-squidington-iii
added
area/connectors
octavia-squidington-iii
added
the
area/documentation
There was a problem hiding this comment.
I tested this with Jira version v3.4.1-dev.18c2e5d364, and it successfully retrieved only the last entry as expected (when creating two new entries it pulled the last updated one + new entries).
Good to go on my end.
bazarnov
approved these changes
Dec 9, 2024
tolik0
approved these changes
Dec 9, 2024
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.
What
Fixes https://github.com/airbytehq/oncall/issues/7008
How
By considering the timezone when creating the str representation of what we send to the API. Indeed, when calling dt.strftime(format), the timezone information is just dropped if not mentioned which leads the interpolation with
timestamplike this one to not have the timezone information as well.I checked quickly and we seem to always be building all the queries using interpolation and not with RequestOptionProvider
start_time_optionwhich therefore should be safe to change for the whole connector.User Impact
Using incremental syncs should lead to less duplication and no data loss
Before code change
https://airbyteio.atlassian.net/rest/api/3/search?fields=%2Aall&jql=updated+%3E%3D+1732877091000+and+project+in+%2810025%29+ORDER+BY+updated+asc&expand=renderedFields%2Ctransitions%2Cchangelog&maxResults=50
https://airbyteio.atlassian.net/rest/api/3/search?fields=%2Aall&jql=updated+%3E%3D+1732877091000+and+project+in+%2810025%29+ORDER+BY+updated+asc&expand=renderedFields%2Ctransitions%2Cchangelog&maxResults=50
As we can see, it creates the same request with epoch 1732877091000 that correspond to 2024-11-29T10:44:51.887 UTC regardless of the timezone in the state
After code change
State with cursor value of 2024-11-29T10:44:51.887+0000
https://airbyteio.atlassian.net/rest/api/3/search?fields=%2Aall&jql=updated+%3E%3D+1732877091000+and+project+in+%2810025%29+ORDER+BY+updated+asc&expand=renderedFields%2Ctransitions%2Cchangelog&maxResults=50
State with cursor value of 2024-11-29T10:44:51.887-0800
https://airbyteio.atlassian.net/rest/api/3/search?fields=%2Aall&jql=updated+%3E%3D+1732905891000+and+project+in+%2810025%29+ORDER+BY+updated+asc&expand=renderedFields%2Ctransitions%2Cchangelog&maxResults=50
State with cursor value of 2024-11-29T10:44:51.887+0800
https://airbyteio.atlassian.net/rest/api/3/search?fields=%2Aall&jql=updated+%3E%3D+1732848291000+and+project+in+%2810025%29+ORDER+BY+updated+asc&expand=renderedFields%2Ctransitions%2Cchangelog&maxResults=50
As we can see, the values are all different now as they consider the timezone when performing the requests.
Can this PR be safely reverted and rolled back?