They’re not deprecating UTC. Did you read the link? They’re deprecating functions that read as authoritative, but are actually naive about timezones, which can less to non-UTC results.
This, I think, is the idea that will be quietly ignored in the long run.
Seconds since start of epoch
If you think UTC means that "time is a number" you are very confused though. UTC has no relation with the UNIX timestamps (and the epoch), though they are both ways to represent a specific point in time.
You are reading to much into a simple question.
> UTC has no relation with the UNIX timestamps (and the epoch),
I said nothing about Unix
The epoch in Swift IIRC is in 2000.
The idea of counting time in seconds since an epoch is ubiquitous. I am unsure if it is universal
It was my mistake for trying to engage. Generally people get downvoted for good reason.
Still I'm confused why you're in this thread at all, which is about a change to an API you don't seem to want to use at all.
That is what they said, but it is inaccurate
All time should be UTC until it is displayed
So a number without a timezone is seconds since epoch in UTC
That is "default" not naive
Some Python applications programmers made stupid mistakes so they change the library
Golly. On the face of it Python is a mess. And it is everywhere. Golly
A "naive" datetime is the one for which it is not known what the timezone is. The opposite is the one for which it is known. You can absolutely encode UTC timezones as seconds since epoch without any additional information (except that one bit that is needed to distinguish them from "naive" ones, which doesn't have to be a literal bit - it can be just a different data type, for example).
And, yes, it would sure be nice if we didn't have "naive" datetimes at all, and everything was always UTC. But there are too many datetimes recorded in the real world without enough information to recover the timezone and thus the precise UTC time, and they still need to be processed. The mistake was to make this the default behavior - but that is a very old one, dating back to earliest days of computing.
True. Fair
> A "naive" datetime is the one for which it is not known what the timezone is.
Then it is UTC
That is what UTC is for.
> Then it is UTC
No, naiive datetime is: "now" ie a time description that lacks enough information to be able to fix that moment relative to other datetimes. It lacks TZ information.
I happen to physically live at roughly 2.6° west of the Greenwich meridian oh and at 50.9 north of the equator. It is now 23:08 (to one minute precision). I have given you enough information to derive my active time zone, if you consult the TZDB, and hence to convert my given naiive datetime to one that will work for you. If I hadn't included both a northing and an easting (I actually gave you a "westing" but that is simply a negative easting!), you could go very wrong. For example France, Spain etc are directly south of here and they are an hour "ahead" of the UK, right now.
Right now it is: "23:15 UTC+0" I could use GMT+0 instead and that would work too but let's keep it French! That's fair - the Greenwich meridian was picked over the Parisian one (and several others) for 0° east/west for time zone calcs but let's call it UTC instead of CUT which is what the english translation would end up being. I actually prefer UTC - CUT is also a word.
Now, I have not included the date bit of datetime in my examples above. There are multiple naiive interpretations for datetime. Calling them all "UTC" is simply not going to cut it 8)
I thought the French way was TUC. UTC is the compromise and/or compatibile wit UT1+UT0.
Says you. The python documentation has never said that naive datetimes are UTC. If the language suddenly makes this assumption, then you break existing code. If you don't want to break existing code, your only option is to 1.) deprecate the existing function and 2.) provide an alternative (which is provide an explicit datetime).
You're absolutely right that it should be, but the problem is that it isn't – Python treats these as belonging to the local time zone.
Software sux
Changing the Python libraries to try to fix buggy software strikes me, on the face of it, as a bad idea.
I am sensitive to this having recently worked with ode that stored time as a string, wall clock local, with no timezone.
And made time series data from it
Software sux, because programmers do silly things
Stop it!