Hacker News new | past | comments | ask | show | jobs | submit login

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.




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


It's hard not to draw the parallel to encodings. Implicit whatever -> Explicit whatever -> Explicit utf8 -> Implicit utf8


What is "utc as numbers"?


> What is "utc as numbers"?

Seconds since start of epoch


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.


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: