[int_19h]

You're focusing on representation where you should be thinking about semantics.

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.

[worik]

> You're focusing on representation where you should be thinking about semantics.

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.

[gerdesj]

>> A "naive" datetime is the one for which it is not known what the timezone is.

> 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)

[dfc]

> I could use GMT+0 instead and that would work too but let's keep it French!

I thought the French way was TUC. UTC is the compromise and/or compatibile wit UT1+UT0.

[nemothekid]

>Then it is UTC

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).

[int_19h]

No, it is not. It is a datetime for which it is not known whether it is UTC or not. Assuming that it is is only marginally less bad than assuming local time.

[skitter]

> Then it is UTC

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.

[worik]

> But there are too many datetimes recorded in the real world without enough information to recover the timezone and thus the precise UTC time

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!