3 ms·
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 t
by 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 agoIt's hard not to draw the parallel to encodings. Implicit whatever -> Explicit whatever -> Explicit utf8 -> Implicit utf8
- remram 3y agoWhat is "utc as numbers"?
- worik 3y ago> What is "utc as numbers"? Seconds since start of epoch
- remram 3y agoYou'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 agoThe 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 agoI'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 agoI 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...