Maya gains an extra microsecond when parsing dates after the year 2243
See original GitHub issueConsider the following program:
import datetime
import maya
d = datetime.datetime(2243, 1, 1, 0, 0, 0, 1)
print(d)
print(str(d))
parsed_d = maya.parse(str(d)).datetime()
print(parsed_d)
print(str(parsed_d))
assert d == parsed_d
2243-01-01 00:00:00.000001
2243-01-01 00:00:00.000001
2243-01-01 00:00:00.000002+00:00
2243-01-01 00:00:00.000002+00:00
Traceback (most recent call last):
File "counterexample.py", line 15, in <module>
assert d == parsed_d
AssertionError
This is a bug introduced somewhere in Maya – I see that Maya is using dateutil for the main machinery of its parse
function, but if I try this with dateutil everything is fine:
import datetime
from dateutil import parser
d = datetime.datetime(2243, 1, 1, 0, 0, 0, 1)
print(d)
print(str(d))
parsed_d = parser.parse(str(d))
print(parsed_d)
print(str(parsed_d))
assert d == parsed_d
2243-01-01 00:00:00.000001
2243-01-01 00:00:00.000001
2243-01-01 00:00:00.000001
2243-01-01 00:00:00.000001
Environment details:
$ pip freeze
dateparser==0.5.0
humanize==0.5.1
iso8601==0.1.11
jdatetime==1.8.1
-e git+git@github.com:kennethreitz/maya.git@6a4ddff215edbdce4a0f5b8bd5ba87710697b7f9#egg=maya-master
python-dateutil==2.6.0
pytz==2016.10
regex==2016.11.21
ruamel.yaml==0.13.4
six==1.10.0
tzlocal==1.3
umalqurra==0.2
wheel==0.24.0
I don’t actually care if you fix this (by 2243, I’ll either be dead, or hopefully have better things to do with my time), but having found it, I thought I’d share.
Yes, I know I’m a terrible person for finding this.
Issue Analytics
- State:
- Created 7 years ago
- Comments:7
Top Results From Across the Web
Datetimes for Humans™ | PythonRepo
Maya gains an extra microsecond when parsing dates after the year 2243. Consider the following program: import datetime import maya d ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
For those who care: the bug is caused by the
float
type having insufficient precision to represent the underlying POSIX timestamp correctly. The further away you get from the POSIX epoch (in either direction), the more precision you’ll lose in the timestamp.I think this is OK.