Parse datetime strings to timezone aware objects #72
Conversation
|
Warning Rate limit exceeded@tkdrob has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 5 minutes and 56 seconds before requesting another review. How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughThe changes involve modifications to datetime handling across multiple files in the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Application
participant Database
User->>Application: Request datetime handling
Application->>Database: Fetch datetime data
Database-->>Application: Return datetime data
Application->>User: Provide datetime response
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (7)
- aiopyarr/models/base.py (4 hunks)
- aiopyarr/models/const.py (1 hunks)
- aiopyarr/models/radarr_common.py (2 hunks)
- tests/test_lidarr.py (35 hunks)
- tests/test_radarr.py (21 hunks)
- tests/test_request.py (13 hunks)
- tests/test_sonarr.py (28 hunks)
Additional context used
Ruff
aiopyarr/models/radarr_common.py
152-152: Do not perform function call
datetime.nowin argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable(B008)
Additional comments not posted (44)
aiopyarr/models/const.py (2)
28-30: New constantRELEASE_TYPESadded.The addition of
RELEASE_TYPESis appropriate for categorizing different types of releases. Ensure that this new constant is used consistently across the application.Run the following script to verify the usage of
RELEASE_TYPES:Verification successful
Usage of
RELEASE_TYPESis consistent and appropriate.The
RELEASE_TYPESconstant is used inaiopyarr/models/radarr_common.pyto iterate over its values, confirming its role in handling different release types. This usage aligns with its intended purpose. No issues found.
aiopyarr/models/radarr_common.py: Iterates overRELEASE_TYPESto handle release types.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all usages of `RELEASE_TYPES` across the application. # Test: Search for the constant usage. Expect: Consistent usage across the application. rg --type python -A 5 $'RELEASE_TYPES'Length of output: 68
Script:
#!/bin/bash # Description: Verify all usages of `RELEASE_TYPES` across the application. # Test: Search for the constant usage. Expect: Consistent usage across the application. rg --type py -A 5 $'RELEASE_TYPES'Length of output: 1298
35-35: Expansion ofCONVERT_TO_DATETIMEto includeRELEASE_TYPES.The inclusion of
RELEASE_TYPESinCONVERT_TO_DATETIMEis a logical extension to handle various release dates. Verify that this change does not impact existing datetime parsing and handling negatively.Run the following script to verify the impact of this change on datetime handling:
aiopyarr/models/base.py (2)
23-28: Removal ofget_datefunction.The removal of
get_datecould potentially impact parts of the codebase that relied on this function. Verify that this removal does not break any existing functionality.Run the following script to verify the impact of removing
get_date:Verification successful
Removal of
get_datefunction verified.The
get_datefunction is not used anywhere in the codebase, indicating that its removal does not impact any existing functionality. No further action is required.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the impact of removing `get_date`. # Test: Search for the usage of `get_date`. Expect: No broken functionality due to its removal. rg --type python -A 5 $'get_date'Length of output: 63
Script:
#!/bin/bash # Description: Verify the impact of removing `get_date`. # Test: Search for the usage of `get_date`. Expect: No broken functionality due to its removal. rg --type py -A 5 $'get_date'Length of output: 1621
23-28: Simplification ofget_datetimefunction.The removal of the
utcparameter simplifies the function but requires verification to ensure it does not negatively impact datetime handling, especially in contexts where UTC conversion was previously necessary.Run the following script to verify the impact of this change on datetime handling:
aiopyarr/models/radarr_common.py (1)
151-153: Enhancement ofreleaseDateTypemethod.The change to accept a
datetimeobject and default to the current time in UTC enhances the method's precision. Verify that this change does not negatively impact date handling or introduce regressions.Run the following script to verify the impact of this change on date handling:
Verification successful
Verification of
releaseDateTypemethod change.The change to accept a
datetimeobject and default to the current time in UTC is verified by existing test cases intests/test_radarr.py. These tests cover various datetime scenarios, ensuring that the method handles date inputs correctly without introducing regressions. No further action is required.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the impact of the changes to `releaseDateType`. # Test: Search for the usage of `releaseDateType`. Expect: No negative impact on date handling. rg --type python -A 5 $'releaseDateType'Length of output: 70
Script:
#!/bin/bash # Corrected script to verify the impact of the changes to `releaseDateType`. # Search for the definition of `releaseDateType` in the codebase. rg --type py -A 5 'def releaseDateType' # Search for the usage of `releaseDateType` across the codebase. rg --type py -A 5 'releaseDateType('Length of output: 625
Script:
#!/bin/bash # Corrected script to verify the impact of the changes to `releaseDateType`. # Search for the definition of `releaseDateType` in the codebase. rg --type py -A 5 'def releaseDateType' # Search for the usage of `releaseDateType` across the codebase with escaped parentheses. rg --type py -A 5 'releaseDateType\('Length of output: 2529
Tools
Ruff
152-152: Do not perform function call
datetime.nowin argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable(B008)
tests/test_sonarr.py (14)
6-11: Refactor: Improved timezone handling using UTC.The changes to import
UTCdirectly from thedatetimemodule, with a fallback totimezone.utcifUTCis not available, are a good practice for clarity and compatibility. This approach ensures that the code is more robust across different Python versions whereUTCmight not be directly available.
68-68: Update: Consistent timezone handling in datetime assertions.The update to use
UTCfor timezone information in the datetime assertion forairDateUtcaligns with the new import strategy and ensures consistent timezone handling across the tests.
124-124: Update: Consistent timezone handling in datetime assertions.The update to use
UTCfor timezone information in the datetime assertion forairDateUtcaligns with the new import strategy and ensures consistent timezone handling across the tests.
140-142: Update: Consistent timezone handling in datetime assertions.The update to use
UTCfor timezone information in the datetime assertion fordateAddedaligns with the new import strategy and ensures consistent timezone handling across the tests.
248-248: Update: Consistent timezone handling in datetime assertions.The update to use
UTCfor timezone information in the datetime assertion forairDateUtcaligns with the new import strategy and ensures consistent timezone handling across the tests.
255-257: Update: Consistent timezone handling in datetime assertions.The update to use
UTCfor timezone information in the datetime assertion fordateAddedaligns with the new import strategy and ensures consistent timezone handling across the tests.
310-310: Update: Consistent timezone handling in datetime assertions.The update to use
UTCfor timezone information in the datetime assertion forfirstAiredaligns with the new import strategy and ensures consistent timezone handling across the tests.
318-318: Update: Consistent timezone handling in datetime assertions.The update to use
UTCfor timezone information in the datetime assertion foraddedaligns with the new import strategy and ensures consistent timezone handling across the tests.
650-652: Update: Consistent timezone handling in datetime assertions.The update to use
UTCfor timezone information in the datetime assertion forestimatedCompletionTimealigns with the new import strategy and ensures consistent timezone handling across the tests.
1279-1279: Update: Consistent timezone handling in datetime assertions.The update to use
UTCfor timezone information in the datetime assertion forairDateUtcaligns with the new import strategy and ensures consistent timezone handling across the tests.
1299-1301: Update: Consistent timezone handling in datetime assertions.The update to use
UTCfor timezone information in the datetime assertion forestimatedCompletionTimealigns with the new import strategy and ensures consistent timezone handling across the tests.
1383-1383: Update: Consistent timezone handling in datetime assertions.The update to use
UTCfor timezone information in the datetime assertion forfirstAiredaligns with the new import strategy and ensures consistent timezone handling across the tests.
1391-1391: Update: Consistent timezone handling in datetime assertions.The update to use
UTCfor timezone information in the datetime assertion foraddedaligns with the new import strategy and ensures consistent timezone handling across the tests.
1402-1402: Update: Consistent timezone handling in datetime assertions.The update to use
UTCfor timezone information in the datetime assertion forairDateUtcaligns with the new import strategy and ensures consistent timezone handling across the tests.tests/test_radarr.py (18)
6-11: Ensure proper handling of the UTC import.The conditional import of
UTCfromdatetimeis a good approach to ensure compatibility across different Python environments. This change is crucial for maintaining timezone awareness throughout the tests.
65-65: Correct implementation of timezone-aware datetime.The assertion for
data.records[0].datecorrectly usesdatetimewithtzinfo=UTC, aligning with the PR's goal to ensure timezone awareness. This is a crucial change for consistency in datetime handling across different time zones.
145-145: Proper use of timezone-aware datetime in assertions.The assertion for
data[0].datecorrectly usesdatetimewithtzinfo=UTC. This change ensures that the tests remain consistent and accurate when dealing with time zones, which is essential for the application's functionality across different regions.
179-182: Ensure consistent timezone handling in calendar-related assertions.The use of
datetimewithtzinfo=UTCforphysicalRelease,digitalRelease, andreleaseDateTypeensures that the tests are robust and timezone-aware. This is particularly important for calendar-related data, which must be accurate and consistent across various time zones.
205-205: Correct implementation of timezone-aware datetime foraddeddate.The assertion for
data[0].addedcorrectly usesdatetimewithtzinfo=UTC. This ensures that the date added is consistently handled across different time zones, which is crucial for accurate record-keeping and functionality.
222-222: Proper handling of timezone in movie file date added.The assertion for
data[0].movieFile.dateAddedcorrectly usesdatetimewithtzinfo=UTC. This change is essential for ensuring that the date and time the movie file was added is accurately recorded and consistent across different time zones.
337-337: Accurate timezone handling for historical data retrieval.The assertion for
data.records[0].datecorrectly usesdatetimewithtzinfo=UTC. This ensures that historical data is handled accurately with respect to time zones, which is crucial for features that rely on date and time calculations.
455-459: Consistent timezone-aware datetime handling in movie release dates.The assertions for
inCinemas,physicalRelease,digitalRelease, and the methodreleaseDateTypecorrectly usedatetimewithtzinfo=UTC. This ensures that all movie release dates are handled consistently and accurately across different time zones, aligning with the PR's objectives.
692-695: Proper timezone handling for cinema and physical release dates.The use of
datetimewithtzinfo=UTCforinCinemasandphysicalReleasedates, as well as the methodreleaseDateType, ensures accurate and consistent handling of these dates across different time zones. This is crucial for features that depend on release timing.
721-721: Correct implementation of timezone-aware datetime foraddeddate.The assertion for
data.addedcorrectly usesdatetimewithtzinfo=UTC. This ensures that the date the movie was added is consistently handled across different time zones, which is crucial for accurate record-keeping and functionality.
738-738: Proper handling of timezone in movie file date added.The assertion for
data.movieFile.dateAddedcorrectly usesdatetimewithtzinfo=UTC. This change is essential for ensuring that the date and time the movie file was added is accurately recorded and consistent across different time zones.
840-840: Accurate timezone handling for movie file date added.The assertion for
data.dateAddedcorrectly usesdatetimewithtzinfo=UTC. This ensures that the date and time the movie file was added is accurately recorded and consistent across different time zones, which is crucial for features that rely on date and time calculations.
989-991: Ensure accurate timezone handling for estimated completion time.The assertion for
data.records[0].estimatedCompletionTimecorrectly usesdatetimewithtzinfo=UTC. This is crucial for accurately predicting and displaying the estimated completion time of tasks across different time zones.
1118-1120: Consistent timezone-aware datetime handling in queue details.The assertion for
data[0].estimatedCompletionTimecorrectly usesdatetimewithtzinfo=UTC. This ensures that the estimated completion time is handled accurately and consistently across different time zones, which is essential for scheduling and time management features.
1218-1224: Accurate handling of movie release dates with timezone awareness.The use of
datetimewithtzinfo=UTCforinCinemas,physicalRelease,digitalRelease, and the methodreleaseDateTypeensures that all movie release dates are handled consistently and accurately across different time zones. This aligns with the PR's objectives to improve date handling.
1246-1246: Proper implementation of timezone-aware datetime foraddeddate.The assertion for
data.movie.addedcorrectly usesdatetimewithtzinfo=UTC. This ensures that the date the movie was added is consistently handled across different time zones, which is crucial for accurate record-keeping and functionality.
1263-1265: Accurate timezone handling for movie file date added.The assertion for
data.movie.movieFile.dateAddedcorrectly usesdatetimewithtzinfo=UTC. This change is essential for ensuring that the date and time the movie file was added is accurately recorded and consistent across different time zones.
1357-1357: Ensure accurate timezone handling for release publish date.The assertion for
data[0].publishDatecorrectly usesdatetimewithtzinfo=UTC. This is crucial for accurately displaying the publish date of releases across different time zones, aligning with the PR's objectives to improve date handling.tests/test_lidarr.py (5)
7-12: Review: Import and Fallback for UTC TimezoneThe import block for the UTC timezone with a fallback to
timezone.utcis a robust solution for ensuring that the tests use timezone-aware datetime objects. This change is crucial for the consistency of datetime comparisons across different environments and is well implemented here.
84-84: Review: Timezone Awareness in Datetime AssertionThe addition of
tzinfo=UTCto the datetime object in the assertion at line 84 is a necessary improvement to ensure that the tests are reliable across different timezone settings. This change aligns with the PR's goal to handle datetime values consistently and accurately.
127-127: Review: Consistent Timezone in Datetime AssertionThe update to include
tzinfo=UTCin the datetime assertion at line 127 ensures that the datetime objects are timezone aware, which is crucial for accurate test results across various environments. This change is in line with the PR's objectives to enhance datetime handling.
299-299: Review: Comprehensive Timezone Handling in Datetime AssertionsThe inclusion of
tzinfo=UTCin the datetime assertions across various lines (299, 315-317, 330, 346-348, 367) ensures that all datetime comparisons are timezone aware. This comprehensive update is crucial for maintaining the accuracy and reliability of the tests across different environments.Also applies to: 315-317, 330-330, 346-348, 367-367
515-515: Review: Uniform Timezone Specification Across TestsThe consistent application of
tzinfo=UTCacross all datetime assertions in various test functions throughout the file ensures uniform timezone handling. This change is essential for the accuracy of datetime comparisons in tests, particularly in a distributed environment where servers might be located in different time zones.Also applies to: 558-558, 606-606, 681-681, 724-724, 870-870, 913-913, 1201-1201, 1210-1212, 1236-1236, 1317-1319, 1513-1515, 1614-1614, 1639-1639, 1708-1710, 1928-1928, 1953-1953, 1996-1998, 2146-2146, 2276-2276, 2314-2314, 2345-2345
tests/test_request.py (2)
7-12: Review of conditional import for UTCThe conditional import of
UTCfrom thedatetimemodule is a robust approach to ensure compatibility across different Python environments. This is particularly useful in environments whereUTCis not available directly underdatetimebut can be accessed throughtimezone.utc. This change enhances the robustness of the code by providing a fallback mechanism.
103-103: Review of datetime assertions with timezoneThe modifications to the datetime assertions in various test cases ensure that all datetime comparisons are made with explicit timezone awareness, specifically using UTC. This is crucial for maintaining consistency and accuracy in datetime handling, especially in test environments where the system timezone might differ from UTC. The changes align with the PR's objective to standardize datetime handling across the codebase.
Also applies to: 126-126, 129-129, 468-468, 488-488, 516-516, 560-560, 599-599, 642-642, 721-731
|
As previously mentioned on Discord, the changes in this PR are more extensive than I expected: Or is the plan that the Home Assistant integration knows @allenporter maybe you could also take a look since you helped with home-assistant/core#118251 |
I agree that it seems like |
| if key == "airDateUtc": | ||
| value = get_datetime(value, utc=True) | ||
| else: | ||
| value = get_datetime(value) |
There was a problem hiding this comment.
What format are the dates returned from the API in this case? and what does ciso8601.parse_datetime do with them?
I assume the logic now is something like:
- if its a utc date, you get a utc date (then assuming .date() wil be correct)
- if its a timesamp aware date, you get a timestamp aware date. (then assuming .date() wil be correct)
- if its no timezone datetime, you get a utc datetime (probably reasonable, then .date() will be correct)
I misread the diffs. This PR is changing some of the |
Proposed change
This PR attempts to fix the error in getting the wrong date for calendar items. All dates are now parsed as UTC if a timezone is not provided in the input string.
Type of change
Additional information
Checklist
make lint)Summary by CodeRabbit
New Features
Bug Fixes
Tests