4 ms·

Sure, my bad. You know what I mean though.

recursive 5y ago
I 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 ago
  while 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 ago
    Those are timestamps, not dates. Each of them fall on two separate dates, depending on time zone.
    - drenvuk 5y ago
      This 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.
      - BurningFrog 5y ago
        I don't think we disagree?
  - josephg 5y ago
    > I ignored what the officially named format was You ignored the officially named format and instead settled on the officially named format. Those are ISO8601 timestamps, specified in UTC time. (The Z at the end means there's (Z)ero timezone offset from UTC). If you're going to talk about a standard, its worth knowing its name.
    - drenvuk 5y ago
      I don't care what the name of something is so long as it does what I want and has a form that I can understand and utilize.

I 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 ago
while 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 ago
  Those are timestamps, not dates. Each of them fall on two separate dates, depending on time zone.
  - drenvuk 5y ago
    This 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.
    - BurningFrog 5y ago
      I don't think we disagree?
- josephg 5y ago
  > I ignored what the officially named format was You ignored the officially named format and instead settled on the officially named format. Those are ISO8601 timestamps, specified in UTC time. (The Z at the end means there's (Z)ero timezone offset from UTC). If you're going to talk about a standard, its worth knowing its name.
  - drenvuk 5y ago
    I don't care what the name of something is so long as it does what I want and has a form that I can understand and utilize.