49 ms·

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

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.

sillysaurusx 3y ago
If that were true, the recommended fix would be to continue using utc (as numbers). Instead, the recommendation is to use datetime objects. This, I think, is the idea that will be quietly ignored in the long run.
- im3w1l 3y ago
  It's hard not to draw the parallel to encodings. Implicit whatever -> Explicit whatever -> Explicit utf8 -> Implicit utf8
- remram 3y ago
  What is "utc as numbers"?
  - worik 3y ago
    > What is "utc as numbers"? Seconds since start of epoch
    - remram 3y ago
      You're free to use numbers instead of the datetime module. In fact you don't have to use any part of the standard library if you don't want to. I don't understand your remarks at all. 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.
      - worik 3y ago
        The question was: 'What is "utc as numbers"?' 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
        remram 3y ago
        I'm reading too much into my own question? This conversation is getting too inscrutable for me. 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.
- sanderjd 3y ago
  I think the recommendation is to use a datetime with the timezone explicitly set to utc? I think the numbers vs. objects thing seems like a distraction...
worik 3y ago
> "naive about timezones" 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
- int_19h 3y ago
  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 3y ago
    > 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.
    - skitter 3y ago
      > 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.
    - nemothekid 3y ago
      >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).

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.

sillysaurusx 3y ago

If that were true, the recommended fix would be to continue using utc (as numbers). Instead, the recommendation is to use datetime objects. This, I think, is the idea that will be quietly ignored in the long run.

im3w1l 3y ago
It's hard not to draw the parallel to encodings. Implicit whatever -> Explicit whatever -> Explicit utf8 -> Implicit utf8
remram 3y ago
What is "utc as numbers"?
- worik 3y ago
  > What is "utc as numbers"? Seconds since start of epoch
  - remram 3y ago
    You're free to use numbers instead of the datetime module. In fact you don't have to use any part of the standard library if you don't want to. I don't understand your remarks at all. 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.
    - worik 3y ago
      The question was: 'What is "utc as numbers"?' 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
      - remram 3y ago
        I'm reading too much into my own question? This conversation is getting too inscrutable for me. 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.
sanderjd 3y ago
I think the recommendation is to use a datetime with the timezone explicitly set to utc? I think the numbers vs. objects thing seems like a distraction...

worik 3y ago

> "naive about timezones" 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

int_19h 3y ago
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 3y ago
  > 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.
  - skitter 3y ago
    > 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.
  - nemothekid 3y ago
    >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).