New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maya gains an extra microsecond when parsing dates after the year 2243 #6
Comments
i think one second of accuracy is acceptable for most use cases :) |
But think of the children*! Seriously though, this looks pretty cool. Props for writing it. (I’ll stop trying to break it now.) 🙂 *’s children’s children’s … children’s need for second-level accurate, human-friendly datetime libraries in the future. |
For those who care: the bug is caused by the |
I think this is OK. |
IMHO this is a valid bug and should be addressed. Perhaps not with super high priority, but although it creeps up past a second in 2243, the inaccuracy is creeping up by various sub-second values on the way there. The solution might not be all that hard, either. What about just storing the date internally as a |
@glyph The inaccuracy creeps up past a microsecond in 2243; it only creeps up past a second in the year 285572427 or so. I don't think using |
@mithrandi Thanks for the correction. The title of the bug did sound pretty extreme (gaining an "extra second") but time is weird and float time doubly so, so I didn't double check :). |
Consider the following program:
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:Environment details:
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.
The text was updated successfully, but these errors were encountered: