5 ms·
>Now it gets saved in a DB as 2021-06-27Z23:00:00 Why would you ever do this? Save it as a JSON date. coolDate.toJSON() would give a timezoned human parse
by drenvuk 5y ago
>Now it gets saved in a DB as 2021-06-27Z23:00:00
Why would you ever do this? Save it as a JSON date.
coolDate.toJSON()
would give a timezoned human parseable date. Just parse it back to the users locale with a built in Date constructor. You can do milliseconds UTC but someone like my younger stupid self would screw it up like most people.
- cbsmith 5y agoIf it's only a date, it probably should be days since the epoch.
- aljarry 5y agoBut starting from which timezone?
- ulrikrasmussen 5y agoIrrelevant for dates. Dates do not refer to a point on the global timeline.
- joelbondurant 5y agoDates ALWAYS have an implicit time zone.
- aljarry 5y agoWhat do you mean? In Auckland _right now_ it's Wednesday, 30th of June, while in Los Angeles it's Tuesday, 29th of June.
- deleted 5y ago[deleted]
- cbsmith 5y agoDates are set against calendar which in turn is set against hourly increments that are offset by local time zones. There is the infamous AoE or "Anywhere on Earth" time zone which can be used to say things like "we won't start until after the 16th Anywhere on Earth", meaning it will at least be the 17th in all timezones before the work gets started, but even in that case, you're referring to an implicit time zone.
- cbsmith 5y agoThe epoch is a specific moment in all time zones. It didn't happen at one moment in Greenwich and then another moment twelve hours later in Auckland & Wellington. Any subsequent moment can be represented based on the amount of time that has passed since that moment. No "which time zone" confusion necessary.
- alach11 5y agoMaybe a better choice would be to use a DateTimeOffset.
- recursive 5y agoJSON date is not a thing.
- drenvuk 5y agoSure, my bad. You know what I mean though.
- recursive 5y agoI really actually don't. Dates in JSON are going to require you to pick a serialization form. ISO8601 seems like a totally reasonable pick. So if not that, then what? Could you give an example?
- drenvuk 5y agowhile developing my project I ignored what the officially named format was and simply checked what converted properly between three browsers. Safari: "2021-06-28T22:59:18.366Z" Chrome: "2021-06-28T23:01:09.131Z" Firefox: "2021-06-28T23:00:14.385Z" The three that I strive to support all utilize this format. YYYY-MM-DDTHH:mm:ss.sssZ. Looking on MDN this seems to call toISOString() which returns a simplified extended ISO format date. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- BurningFrog 5y agoThose are timestamps, not dates. Each of them fall on two separate dates, depending on time zone.
- drenvuk 5y agoThis is why dates are such an issue. A timestamp is the number of seconds or milliseconds or units like 1624938650 seconds from epoch UTC. What I posted above are human parseable datetimes in ISO 8601. Each of them is a point in time that depending on the locale and tz fall on two separate dates but the most important aspect is that it doesn't matter whether I'm using them in my DB or on a user's machine in a different locale and tz. That's the point.
- afavour 5y agoThat works great when every interaction you make with the data is in JS. But less so if you want to, say, run manual SQL queries from time to time.
- drenvuk 5y agoThey're sortable. I don't see what the issue is. Can you explain?