Improve pattern for timestamp values

[epursimuove]

Great initiative with this OvertureMaps project!

One thing that I noted is about how timestamps are handled within the Schema Reference (for example the updateTime property in https://docs.overturemaps.org/reference/places/place).

The current pattern for these timestamps seems to be defined as

^[1-9]\d{3}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d{3})?(Z|[-+]\d{2}:\d{2})?$

which I think can be improved, since this format may be too complex and also will let invalid "timestamp" values through if leaving the pattern as is.

When testing the strings 2023-02-22T23:55:01-08:00 and 2023-02-22T23:55:01Z they are both matching the pattern, which may be okay. The string 2023-02-22T23:55:01 is also matching, which I think is not okay since this is actually a local datetime value and NOT an actual timestamp.

My suggestion

If there are no requirements to actually support different time zones for these timestamps, I would argue that it is way better to have a pattern like

^[1-9]\d{3}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d{3})?Z$

which will only match 2023-02-22T23:55:01Z (the one using the UTC timezone) of the three examples from above.

Most often there are no (good) requirements to support different time zones when you want to handle a timestamp.

My detailed arguments about how to handle timestamps in general and the difference between timestamp and local datetime can be found here: https://anders.nemonisimors.com/timestamps.php

[vcschapp]

Hi Anders,
Thanks for raising this for discussion.

You're absolutely right, that is the pattern.

Of the three patterns you showed that match (click here for live test):

1. 2023-02-22T23:55:01-08:00 - this is valid and intentional, but I think your point is it may not be desirable...
2. 2023-02-22T23:55:01Z - this is valid and intentional and I think desirable also.
3. 2023-02-22T23:55:01 - this is invalid and not intentional and is definitely a bug!

For #3, I will cut a bug issue, so we can fix this, hopefully for the next schema update, or soon thereafter.

For #1 I will cut an issue for internal discussion. I agree with your point that the Z variant is probably sufficient, and is simpler. I suspect the intention in trying to support time zones was that the JSON Schema date-time validation officially supports RFC-3339, which does support numeric offsets from UTC.

---

By the way, loved your website and cogent thoughts on the topic there.

[vcschapp]

By the way, we don't yet have a public issues list on GitHub, it's private, so the existence of the issues I'm creating will be opaque for a time. But I do believe we intend to open up the issues list once the organization matures a bit.

[vcschapp]

Created the bug issue. (Schema WG #179.)

[vcschapp]

Created the internal discussion issue. (Schema WG #180.)

[epursimuove]

Just let me know if I can be of any more help.

[vcschapp]

@epursimuove, we recently merged a bug fix to the schema dev branch to fix the pattern issue. That should be part of the upcoming mid-February release. The other suggested change is still in the queue for prioritization.