5 ms·

Which ISO-8601 format though? There are a variety to choose from. You want the date-only format? or the date+time format? you want the T separator or space?

Which ISO-8601 format though? There are a variety to choose from. You want the date-only format? or the date+time format? you want the T separator or space? Is time zone represented? All these are allowed according to the ISO standard.

ncallaway 6y ago
> You want the date-only format? or the date+time format? If your data field conceptually represents a date (such as a date of birth, or the user's selection in the input of a date), use the ISO-8601 date. If your data field represents a time (such as the selection of the time when a daily should recur each day), then you should use the ISO-8601 format with of a time. If your data field represents a specific point in time (such as the time an action happened), then you should use the full representation of the date and time. > you want the T separator or space? When concatenating the date and time, the 'T' separator is used. Although, this is an implementation detail I've never had to touch myself, since every date library I've ever used has been able to format dates into an ISO format, and parse them from an ISO format without me having to consider the separator. > Is time zone represented? Again, this depends on what the data being represented fundamentally is. If it's a point in time that an event happened, yes. _Usually_ if you're representing a full date & time the answer is yes, you should represent the time-zone (I always serializing these dates in UTC and include the TZ). The TZ should only be forgone if the data represents the abstract notion of a specific date and time, rather than a specific point in time. To me (other than the "T" separator), these are all fundamental data questions, and not serialization questions. You need to know whether a field is a DATE, a TIME, a DATETIME and whether is a Zoned Date Time or a Local Date Time regardless of your serialization format. ISO-8601 conveniently supports all these uses-cases and more.
em500 6y ago
Sure, but all of those variations can be parsed unambigously as long as it's communicated to be an ISO-8601 datetime.

ncallaway 6y ago

> You want the date-only format? or the date+time format? If your data field conceptually represents a date (such as a date of birth, or the user's selection in the input of a date), use the ISO-8601 date. If your data field represents a time (such as the selection of the time when a daily should recur each day), then you should use the ISO-8601 format with of a time. If your data field represents a specific point in time (such as the time an action happened), then you should use the full representation of the date and time. > you want the T separator or space? When concatenating the date and time, the 'T' separator is used. Although, this is an implementation detail I've never had to touch myself, since every date library I've ever used has been able to format dates into an ISO format, and parse them from an ISO format without me having to consider the separator. > Is time zone represented? Again, this depends on what the data being represented fundamentally is. If it's a point in time that an event happened, yes. _Usually_ if you're representing a full date & time the answer is yes, you should represent the time-zone (I always serializing these dates in UTC and include the TZ). The TZ should only be forgone if the data represents the abstract notion of a specific date and time, rather than a specific point in time. To me (other than the "T" separator), these are all fundamental data questions, and not serialization questions. You need to know whether a field is a DATE, a TIME, a DATETIME and whether is a Zoned Date Time or a Local Date Time regardless of your serialization format. ISO-8601 conveniently supports all these uses-cases and more.

em500 6y ago

Sure, but all of those variations can be parsed unambigously as long as it's communicated to be an ISO-8601 datetime.