3 ms·

Just use a string and ISO 8601? “2018-03-25”

by continuational 8y ago

wildrhythms 8y ago
What's the timezone?
- lysium 8y ago
  Do you need a time zone for dates?
  - wildrhythms 8y ago
    Consider if I'm storing a user's (local) birthday on my server: {..., "birthday": "2018-03-25"} If my server is located in New York City, and the user is in Sydney, then my server isn't going to wish them happy birthday in time. So maybe we could do: {..., "birthday": "2018-03-25", "location": "Sydney/AU"} But at this point we might as well use a standardized time format (UTC) with a timezone offset. Maybe I'm thinking too far into it?
    - webXL 8y ago
      ISO 8601 has you covered: Year: YYYY (eg 1997) Year and month: YYYY-MM (eg 1997-07) Complete date: YYYY-MM-DD (eg 1997-07-16) Complete date plus hours and minutes: YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00) Complete date plus hours, minutes and seconds: YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00) Complete date plus hours, minutes, seconds and a decimal fraction of a second YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00) where: YYYY = four-digit year MM = two-digit month (01=January, etc.) DD = two-digit day of month (01 through 31) hh = two digits of hour (00 through 23) (am/pm NOT allowed) mm = two digits of minute (00 through 59) ss = two digits of second (00 through 59) s = one or more digits representing a decimal fraction of a second TZD = time zone designator (Z or +hh:mm or -hh:mm)
emodendroket 8y ago
Wow, I can "just" use that, thanks. The problem is that JSON is an interchange format, meaning that I need to implement this serialization and deserialization quirk on every producer/consumer of my API (which, you know, avoiding is kind of the point of using a standard interchange format). Furthermore, because everything is a string, I can't unambiguously indicate something is meant to be a string in that format rather than a date.

Just use a string and ISO 8601? “2018-03-25”

wildrhythms 8y ago

What's the timezone?

lysium 8y ago
Do you need a time zone for dates?
- wildrhythms 8y ago
  Consider if I'm storing a user's (local) birthday on my server: {..., "birthday": "2018-03-25"} If my server is located in New York City, and the user is in Sydney, then my server isn't going to wish them happy birthday in time. So maybe we could do: {..., "birthday": "2018-03-25", "location": "Sydney/AU"} But at this point we might as well use a standardized time format (UTC) with a timezone offset. Maybe I'm thinking too far into it?
  - webXL 8y ago
    ISO 8601 has you covered: Year: YYYY (eg 1997) Year and month: YYYY-MM (eg 1997-07) Complete date: YYYY-MM-DD (eg 1997-07-16) Complete date plus hours and minutes: YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00) Complete date plus hours, minutes and seconds: YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00) Complete date plus hours, minutes, seconds and a decimal fraction of a second YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00) where: YYYY = four-digit year MM = two-digit month (01=January, etc.) DD = two-digit day of month (01 through 31) hh = two digits of hour (00 through 23) (am/pm NOT allowed) mm = two digits of minute (00 through 59) ss = two digits of second (00 through 59) s = one or more digits representing a decimal fraction of a second TZD = time zone designator (Z or +hh:mm or -hh:mm)

emodendroket 8y ago

Wow, I can "just" use that, thanks. The problem is that JSON is an interchange format, meaning that I need to implement this serialization and deserialization quirk on every producer/consumer of my API (which, you know, avoiding is kind of the point of using a standard interchange format). Furthermore, because everything is a string, I can't unambiguously indicate something is meant to be a string in that format rather than a date.