undefined | Better HN

0 pointsmanigandham6y ago0 comments

Yes it is. An instant expressed as a Unix epoch is a date in UTC. The sender converts any non-UTC date to UTC and then to unix time. The receiver parses unix time to a UTC date, and then converts to any timezone necessary. What's the problem?

If you're using code that doesn't know how to handle UTC or converts it automatically to some server/env timezone, or doesn't check the timezone of the dates then that's a problem with that code, and has nothing to do with JSON or unix time.

0 comments

4 comments · 2 top-level

sixbrx6y ago· 2 in thread

you've not addressed the points above, I'm out

manigandhamOP6y ago

There was no point other than incorrectly parsing a unix timestamp to something other than UTC. If you need to pass the time zone then pass it separately or use an ISO format instead. None of this is that complicated.

masklinn6y ago

The point is that a date is not the same thing as an instant. A unix timestamp captures an instant, but that may not be suitable or desirable to a specific use case e.g. instants are usually broken when it comes to scheduling future events as the mapping might change inbetween the recording and occurrence, and you want this change to be reflected on your execution.

dwaite6y ago

I believe his point was that an instant in time (be it seconds since epoch or represented in some other way) is not the same as the representation of a calendar day - string-formatted standards let you represent concepts other than an instant.

The confusion might be coming from JavaScript incorrectly calling its instant representation Date, when it is actually quite a bit more precise than that.

Its also worth noting that you can't pick a time like 12:00 UTC and have it retain the calendar day in all time zones, because there are a few stray islands which are UTC+14 rather than UTC-10.

j / k navigate · click thread line to collapse