Skip to content

Conversation

remarkov
Copy link
Contributor

Apparently Apple started to use nanoseconds in the response payload which cannot be parsed properly with stdlib without string manipulations, thus producing the errors like

ValueError time data '2025-05-23T09:50:03.168550349-07:00' does not match format '%Y-%m-%dT%H:%M:%S.%f%z'

As there is already some inconsistency in the API responses that requires additional logic, instead of complicating it further we can introduce a dependency of dateutil which handles all these properly:

In [2]: from dateutil.parser import parse
In [3]: parse("2021-01-28T06:01:32-08:00")
Out[3]: datetime.datetime(2021, 1, 28, 6, 1, 32, tzinfo=tzoffset(None, -28800))
In [4]: parse("2020-08-04T11:44:12.000+0000")
Out[4]: datetime.datetime(2020, 8, 4, 11, 44, 12, tzinfo=tzutc())
In [5]: parse("2025-05-23T09:50:03.168550349-07:00")
Out[5]: datetime.datetime(2025, 5, 23, 9, 50, 3, 168550, tzinfo=tzoffset(None, -25200))

@remarkov remarkov requested a review from priitlatt May 23, 2025 20:33
Copy link
Contributor

@priitlatt priitlatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update version in here too:

__version__ = "0.58.1.dev"

It makes no difference for releases, but I still prefer to keep it up to date. Makes it easier when working with multiple versions that are installed side-by-side.

Other than that looks good.

@priitlatt
Copy link
Contributor

Perhaps add couple of additional test cases too for new cases? Existing tests for datetime conversions can be found here:

@pytest.mark.parametrize(
"iso_8601_timestamp, expected_datetime",
[
(None, None),
(datetime(2020, 8, 4, 11, 44, 12, tzinfo=timezone.utc), "2020-08-04T11:44:12.000+0000"),
(datetime(1970, 1, 1, 0, 0, 0, tzinfo=timezone.utc), "1970-01-01T00:00:00.000+0000"),
],
)
def test_to_iso_8601(iso_8601_timestamp, expected_datetime):
assert Resource.to_iso_8601(iso_8601_timestamp) == expected_datetime
@pytest.mark.parametrize(
"given_datetime, expected_iso_8601_timestamp",
[
(None, None),
("2020-08-04T11:44:12.000+0000", datetime(2020, 8, 4, 11, 44, 12, tzinfo=timezone.utc)),
(
"2021-01-28T06:01:32-08:00",
datetime(2021, 1, 28, 6, 1, 32, tzinfo=timezone(timedelta(days=-1, seconds=57600))),
),
("1970-01-01T00:00:00.000+0000", datetime(1970, 1, 1, 0, 0, 0, tzinfo=timezone.utc)),
],
)
def test_from_iso_8601(given_datetime, expected_iso_8601_timestamp):
assert Resource.from_iso_8601(given_datetime) == expected_iso_8601_timestamp

@mikhail-tokarev mikhail-tokarev changed the title Fix parsing datetime with nanoseconds in Apple API response Fix parsing datetime with nanoseconds in Apple API response (CM-243) May 27, 2025
@mikhail-tokarev mikhail-tokarev changed the title Fix parsing datetime with nanoseconds in Apple API response (CM-243) Fix parsing datetime with nanoseconds in Apple API response May 27, 2025
@hj-kang-mercari
Copy link

We are also struggling with this error. We hope this pull request will be merged and deployed soon.

Copy link
Contributor

@priitlatt priitlatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Version 0.58.2 was already released yesterday. So version needs to be bumped once more.

@remarkov
Copy link
Contributor Author

@priitlatt thanks for the review, addressed comments and suggestions

@remarkov remarkov requested a review from priitlatt May 28, 2025 09:19
Copy link
Contributor

@priitlatt priitlatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@remarkov remarkov merged commit b7087c0 into master May 28, 2025
13 checks passed
@remarkov remarkov deleted the bugfix/support-nanoseconds-in-apple-api branch May 28, 2025 09:19
@priitlatt
Copy link
Contributor

@hj-kang-mercari, this fix was just released in v0.58.3.

@hj-kang-mercari
Copy link

@hj-kang-mercari, this fix was just released in v0.58.3.

Thanks a lot, @priitlatt and @remarkov. I love to hear that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants