Local datetimes

[heidivanparys]

According to recommendation 3 (/req/core/format-and-pattern), the value of a property with DateTime as type in the UML model can be a local datetime.

The regular expression (^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d)?(Z|((\+|-)\d{2}:\d{2}))?$) indicates this, and it also confirmed in the note “However, applications may also use different regular expressions. For example, a community may choose to only allow date time values in Zulu time (i.e., requiring the time zone designator to always be ‘Z’).”.

JSON Schema Validation: A Vocabulary for Structural Validation of JSON states:

Date and time format names are derived from RFC 3339, section 5.6 [RFC3339]. The duration format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339. Implementations supporting formats SHOULD implement support for the following attributes:

date-time: A string instance is valid against this attribute if it is a valid representation according to the "date-time' ABNF rule (referenced above)

date: A string instance is valid against this attribute if it is a valid representation according to the "full-date" ABNF rule (referenced above) time: A string instance is valid against this attribute if it is a valid representation according to the "full-time" ABNF rule (referenced above) duration: A string instance is valid against this attribute if it is a valid representation according to the "duration" ABNF rule (referenced above)

From RFC 3339:

5.6. Internet Date/Time Format

The following profile of ISO 8601 [ISO8601] dates SHOULD be used in new protocols on the Internet. This is specified using the syntax description notation defined in [ABNF].

date-fullyear = 4DIGIT date-month = 2DIGIT ; 01-12 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on ; month/year time-hour = 2DIGIT ; 00-23 time-minute = 2DIGIT ; 00-59 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second ; rules time-secfrac = "." 1*DIGIT time-numoffset = ("+" / "-") time-hour ":" time-minute time-offset = "Z" / time-numoffset

partial-time = time-hour ":" time-minute ":" time-second [time-secfrac] full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset

date-time = full-date "T" full-time

and also relevant are the following:

4.1. Coordinated Universal Time (UTC)

Because the daylight saving rules for local time zones are so convoluted and can change based on local law at unpredictable times, true interoperability is best achieved by using Coordinated Universal Time (UTC). This specification does not cater to local time zone rules.

So, as far as I can see, using format=date-time as specified in JSON Schema Validation: A Vocabulary for Structural Validation of JSON implies using a datetime in UTC or a datetime with a UTC offset specified.

That would mean that the regular expression for DateTime should be updated.

Perhaps a format for local datetimes could be defined by the best practice (allowed according to https://json-schema.org/draft/2020-12/json-schema-validation.html#name-custom-format-attributes)?

[jechterhoff]

Thank you for pointing this out, Heidi.

Rather than inventing a new format, I propose to just update the regular expressions, so that the time-offset is mandatory there:

• DateTime: ^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d)?(Z|((\+|-)\d{2}:\d{2}))$
• Time: ^\d{2}:\d{2}:\d{2}(\.\d)?(Z|((\+|-)\d{2}:\d{2}))$

Since this is only a recommendation, a community can use a pattern with optional time-offset.

@heidivanparys Do you agree?

[heidivanparys]

@jechterhoff Ok with me.