This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author p-ganssle
Recipients Sam Wainwright, belopolsky, p-ganssle
Date 2019-08-31.20:56:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1567285001.76.0.680185616625.issue37992@roundup.psfhosted.org>
In-reply-to
Content
This is only a semi-arbitrary restriction. Realistically, `datetime` is not a particularly good way to represent times much older than the 17th or 18th century (and if you're using time zones, it gets increasingly inaccurate as you go further back from 1970 or the further in the future you go from the current time). Generally, I think the choice to keep it to positive dates is due to a combination of the fact that 1. it introduces a lot more edge cases (there's no year 0, for example) 2. it may invalidate otherwise perfectly acceptable assumptions that people have made in code about the sign of the component values and 3. it would be a rarely used feature of dubious utility. I am not sure that adding this feature would be worth the support burden it would bring.

There was a discussion about this on the discourse in the past, there wasn't an obvious consensus that it would never happen, but I would not say that there was much support for the idea: https://discuss.python.org/t/bc-date-support/582/2
History
Date User Action Args
2019-08-31 20:56:41p-gansslesetrecipients: + p-ganssle, belopolsky, Sam Wainwright
2019-08-31 20:56:41p-gansslesetmessageid: <1567285001.76.0.680185616625.issue37992@roundup.psfhosted.org>
2019-08-31 20:56:41p-gansslelinkissue37992 messages
2019-08-31 20:56:41p-gansslecreate