Hi folks, I'm unsure if this is expected behavior due to the subtleties of all things time related, but it feels like a bug from where I'm sitting. Certain timestamps seem to be stored incorrectly. Maybe someone here could tell me if there's anything I can do to ensure that the timestamp out matches the one going in?

As shown here below, calling datetime.fromisoformat() on the same timestamp string stores the expected datetime object and reproduces the original string; however, parse produces a datetime object that differs in the microsecond's place.

The other obvious difference -- beyond the microsecond mismatch -- is that the timezone is stored differently. I expect something is going on there, but I neither know enough to say what is going on, nor know if anything can be done to remedy the situation or even work around.

Python 3.11.3 (main, Aug 28 2023, 16:26:17) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import parse
>>> s = "my timestamp 2023-10-14T15:09:08.501902Z won't reproduce"
>>> pattern = "p {my_time:ti} w"
>>> out_pat = "my timestamp {my_time:%Y-%m-%dT%H:%M:%S.%fZ} won't reproduce"
>>> 
>>> r = parse.search(pattern, s)
>>> r
<Result () {'my_time': datetime.datetime(2023, 10, 14, 15, 9, 8, 501901, tzinfo=<FixedTzOffset UTC 0:00:00>)}>
>>> out_s = out_pat.format(**r.named)
>>> out_s
"my timestamp 2023-10-14T15:09:08.501901Z won't reproduce"
>>> s == out_s
False
>>> 
>>> 
>>> 
>>> stamp = '2023-10-14T15:09:08.501902Z'
>>> from datetime import datetime as dt
>>> d = dt.fromisoformat(stamp)
>>> d
datetime.datetime(2023, 10, 14, 15, 9, 8, 501902, tzinfo=datetime.timezone.utc)
>>> out = out_pat.format(my_time=d)
>>> out
"my timestamp 2023-10-14T15:09:08.501902Z won't reproduce"
>>> s == out
True

Other timestamps don't suffer the same issue, here I changed the tenths of a second from 5 to 6:

>>> s = "my timestamp 2023-10-14T15:09:08.601902Z would reproduce fine"
>>> r = parse.search(pattern, s)
>>> r
<Result () {'my_time': datetime.datetime(2023, 10, 14, 15, 9, 8, 601902, tzinfo=<FixedTzOffset UTC 0:00:00>)}>

and I'm not sure why. If I could predict which ones would be off-by-one, I could work around the issue, though -- obviously -- that's not ideal.

Thanks for help in advance, thanks for a great utility, and please let me know if there's any other info I can provide that would be helpful!