4 ms·

One advantage of getting older is that you see a lot of change. In the long run, simple ideas tend to win. And there have been lots of cases where the programmi

One advantage of getting older is that you see a lot of change. In the long run, simple ideas tend to win. And there have been lots of cases where the programming world collectively agreed that some more complex idea was the right way, then a decade later everyone has reverted to the simple idea. UTC is simple and unambiguous. Time is a number representing a fixed point in time. When displaying it for humans, convert it into human form. When this principle is applied everywhere, it’s hard to make mistakes. My gut says that deprecating utc as the native time representation will be one of those ideas fervently embraced by a few, ignored by most, and then quietly forgotten about in a decade.

p5a0u9l 3y ago
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).
globular-toast 3y ago
All of this is fine if you are talking about timestamps. But Python's datetime library can do more than that. Basically once you get into future dates that it all starts to fall apart.
ryandrake 3y ago
It doesn't seem like they're deprecating "utc as the native time representation." They're just making it harder to get a datetime object that "has no time zone." The message with this change is: Go ahead and keep using UTC, but explicitly specify it, and the object itself will know it's own UTC-ness.
Spivak 3y ago
This misses what the change actually is. Python has two datetimes, one which includes the timezone info and one which doesn't (naive). There is no assumed timezone for naive datetimes and different software treats it differently. What's being deprecated is methods to create naive datetimes that are implicitly UTC without just attaching that information to the object itself. In the new world everything is still in UTC and you convert to local time at the last minute but now you can be sure that the datetime object you got handed is actually UTC instead of it being a convention that isn't always honored.
gizmo 3y ago
Good point. Also, as long as javascript will happily convert an integer into a new Date() people will want obvious compatibility in Python.
happytoexplain 3y ago
Time is two different things. Just making everything UTC until display time is incompatible with that. Sometimes you need to operate on calendar units or clock units as part of business logic.
- worik 3y ago
  > Sometimes you need to operate on calendar units or clock units as part of business logic. And you must do it in UTC
  - erik_seaberg 3y ago
    To make something happen at 9 AM every day in the user’s time zone, choosing UTC will make it harder.
    - worik 3y ago
      Needs must. But otherwise use UTC A local time aware process has to be available for users. Of course But in the backend it is UTC Storing time any other way is a world of pain
      - Dylan16807 3y ago
        > But in the backend it is UTC Scenario 1: You have an event to schedule at 9am local at some future date. You want to convert to UTC. But you can only do that if you know the offset, and the offset for future dates can change or be unknown. How do you resolve this? Scenario 2: Now the event is "9am every day, indefinitely". How do you represent that as UTC? Do you generate tens of thousands of separate timestamps?

p5a0u9l 3y ago

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

globular-toast 3y ago

All of this is fine if you are talking about timestamps. But Python's datetime library can do more than that. Basically once you get into future dates that it all starts to fall apart.

ryandrake 3y ago

It doesn't seem like they're deprecating "utc as the native time representation." They're just making it harder to get a datetime object that "has no time zone." The message with this change is: Go ahead and keep using UTC, but explicitly specify it, and the object itself will know it's own UTC-ness.

Spivak 3y ago

This misses what the change actually is. Python has two datetimes, one which includes the timezone info and one which doesn't (naive). There is no assumed timezone for naive datetimes and different software treats it differently. What's being deprecated is methods to create naive datetimes that are implicitly UTC without just attaching that information to the object itself. In the new world everything is still in UTC and you convert to local time at the last minute but now you can be sure that the datetime object you got handed is actually UTC instead of it being a convention that isn't always honored.

gizmo 3y ago

Good point. Also, as long as javascript will happily convert an integer into a new Date() people will want obvious compatibility in Python.

happytoexplain 3y ago

Time is two different things. Just making everything UTC until display time is incompatible with that. Sometimes you need to operate on calendar units or clock units as part of business logic.

worik 3y ago
> Sometimes you need to operate on calendar units or clock units as part of business logic. And you must do it in UTC
- erik_seaberg 3y ago
  To make something happen at 9 AM every day in the user’s time zone, choosing UTC will make it harder.
  - worik 3y ago
    Needs must. But otherwise use UTC A local time aware process has to be available for users. Of course But in the backend it is UTC Storing time any other way is a world of pain
    - Dylan16807 3y ago
      > But in the backend it is UTC Scenario 1: You have an event to schedule at 9am local at some future date. You want to convert to UTC. But you can only do that if you know the offset, and the offset for future dates can change or be unknown. How do you resolve this? Scenario 2: Now the event is "9am every day, indefinitely". How do you represent that as UTC? Do you generate tens of thousands of separate timestamps?