does pubtime need a Z

[petersilva]

tt-protocols earlier work was to simply assert that all date/times are in UTC. work from other communities consistently includes Z postfix.

Is this necessary?

[josusky]

That is a mere trifle. Actually, current definition permits it:

  "properties": {
    "pubTime": {
      "$id": "#/properties/pubTime",
      "format": "regex",
      "pattern": "[0-9]{8}T[0-9]{6}(\\.[0-9]+)?Z?",
      "type": "string",
      "title": "Publication time",
      "description": "Time of ingestion into the mesh. ISO 8601.",
      "examples": [
        "20190213T123456.789Z"
      ]
    },

So we just need to adjust the description from:

... In the meteorological domain, UTC is more natural. Leaving the Z out seems reasonable.

to something like: "... In the meteorological domain, UTC is more natural. Therefore, if the Z is not present the recipient shall assume UTC. However, the producers of the notifications are advised to include the time zone indication ("Z") to avoid ambiguity."

[golfvert]

According to ISO 8601 (see https://en.wikipedia.org/wiki/ISO_8601) when Z is omitted:

Local time (unqualified)
If no UTC relation information is given with a time representation, the time is assumed to be in local time. While it may be safe to assume local time when communicating in the same time zone, it is ambiguous when used in communicating across different time zones. Even within a single geographic time zone, some local times will be ambiguous if the region observes [daylight saving time](https://en.wikipedia.org/wiki/Daylight_saving_time). It is usually preferable to indicate a time zone (zone designator) using the standard's notation.

So, as we want to avoid ambiguity between UTC (Z) and localtime, and as the standard says otherwise (default being localtime), we must have a "Z".

[petersilva]

Committee consensus: Agree to add mandatory Z.