4 ms·
That's not the point, the point is an instant is not a date. And common ways of getting the date from an instant are likely to give you the date of the instant
by sixbrx 7y ago
That's not the point, the point is an instant is not a date. And common ways of getting the date from an instant are likely to give you the date of the instant interpreted in your current timezone for your computing env (which is often what is wanted such as when displaying for a user), so when you extract the date portion, it is not the intended one. So it's not that there's an easy right way of doing it, of course there is - but there are also easy wrong ways which also seem obvious.
Also, forget about the receiving side, you're also assuming that the sending side meant the date for the instant as at offset 0 instead of in their own timezone (which is probably how the instant is being displayed for them). From experience, that's not a safe assumption - witness any instant meant to mean "today's date here and now" derived from a now() call alone or truncated to have 0 time parts (in current time zone!) - I see that attempted a lot. Way too error prone especially when you don't control both sides.
- manigandham 7y agoYes 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.
- sixbrx 7y agoyou've not addressed the points above, I'm out
- manigandham 7y agoThere 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.
- masklinn 7y agoThe 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.
- dwaite 7y agoI 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.