So why would you want to work with naive datetimes in the first place?Īn application may be designed in such a way that all dates and times are in a single timezone that is known in advance. To me it is clear that the Python maintainers behind this deprecation have a problem with naive datetimes and are using this supposed problem as an excuse to cripple them. ![]() I may be missing something here, but I don't really follow this logic. They think that because a few functions assume that naive timestamps represent local times, all naive uses that are not in local time should be discouraged. This is really the bug, but instead of fixing the broken implementations of these methods they are now trying to force people to move to aware datetimes by deprecating the two main functions that generate naive ones. These methods should have been designed to fail when a naive datetime object is passed to them, but for some strange reason they decided that when a timezone is not provided the timezone from the system should be used. So basically, at some point they've added a datetime.timestamp() method (and possibly others as well) that accept both aware and naive datetimes and this was a mistake, because these methods must have a timezone to work. This sounded strange, so I had to go and check, and sure enough, the timestamp() method that returns the incorrect UNIX time in the example was introduced in Python 3.3 and nothing similar appears to have existed back in Python 2 times. If you read the issue linked above, they suggest that this ambiguity did not exist in Python 2 and for that reason this was not a problem for a long time, but it now is and needs to be addressed. So we have a UNIX timestamp that originated as midnight on January 1st, 1970, and after being converted to a datetime and back ends up as 5 am. When this object is converted back to a timestamp, the dt.timestamp() method finds that it does not have a timezone to use in the conversion, so it uses the computer's own timezone, which in this example was EST (note that the EST timezone is 5 hours, or 18,000 seconds behind UTC). First, dt is assigned a naive datetime that is converted from the "zero" time or UNIX epoch, which is January 1st, 1970 at midnight. ![]() The example above was executed on a computer that was configured for Eastern Standard Time (EST). There is a GitHub issue from 2019 that provides some background into this, with the following example: > from datetime import datetime The specific issue is that some Python date and time functions accept naive timestamps and assume that they represent local time, according to the timezone that is configured on the computer running the code. I would have made it more clear that these functions work with naive time, maybe by calling them naive_utcnow() and naive_utcfromtimestamp().īut their names are not the problem here. A function that is called utcnow() should be expected to return UTC datetimes, as implied by the name. If you ask me, I think the names of these functions are misleading. This is in contrast to "aware" datetime objects, which do have a timezone attached to them explicitly. A naive datetime object is one that does not have a timezone, which means that it can only be used in a context where the timezone does not matter or is already known in advance. The problem that the Python maintainers have found comes from the fact that these functions return "naive" datetime objects. What's Wrong with utcnow() and utcfromtimestamp()? ![]() In this short article I'll tell you more about why these functions are getting the axe, and what to replace them with. If you have followed my web development tutorials you must have seen me use utcnow() a lot, so I will clearly need to re-train myself to use an alternative, in preparation for the eventual removal of this function (likely a few years out, so no need to panic!). ![]() I was going through the release notes of the new Python 3.12 version the other day, and one item caught my attention in the deprecations section:ĭatetime.datetime’s utcnow() and utcfromtimestamp() are deprecated and will be removed in a future version.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |