Concerto assumes UTC for unqualified "Local Time" DateTime values

[mttrbrts]

Concerto assumes UTC for unqualified "Local Time" DateTime values

[DS-AdamMilazzo]

When an unqualified date, or date-time value is provided (i.e. one without an explicit Z or offset component), users expect the date to be interpreted as in their local timezone. This aligns with the ISO 8601 specification
https://en.wikipedia.org/wiki/ISO_8601#Local_time_(unqualified)

Local time (unqualified)
If no UTC relation information is given with a time representation, the time is assumed to be in local time.

First, In the example you gave, there is no time representation, only a date representation. The value has no time zone at all and the snippet from ISO 8601 does not apply. (But as you mentioned, the bug report applies to date-times as well.)

Perhaps some users expect it to assume local time, but it's not what I, as a user, would expect. I would expect a date-time with no time-zone information to be assumed to be in UTC (if an assumption must be made at all). This is a data interchange format, not an interactive user interface. The interpretation of a value shouldn't change as the data crosses time zones. So I would expect it to assume UTC.

Furthermore, "assume local time" makes no sense when dealing with a service, as in the case of the model registry, because the "local time" would be the local time of some remote server. The server would not know the user's local time. I know that the model registry apparently runs with a "local time" of UTC, and so doesn't exhibit the buggy behavior, but in general the server should not be reinterpreting user timestamps according to its own local time zone. Whether this means Concerto should behave differently in client-side and server-side scenarios, I can't say, but my vote would be "no".

• Explicitly detect usage of date-times without a zone designation, and to assume an offset that matches the local offset of the user's machine/server.
• Use of the --utcOffset flag in the CLI should always allow the offset to be set explicitly.

I think a better solution is: 1) assume times are in UTC unless otherwise specified, 2) if you must normalize date-times, normalize them to UTC (or else leave their time zones alone), and 3) if you can, stop treating dates as date-times.

[mttrbrts]

We now have an interim solution in 3.3 that allows clients to specify more strict behaviour. This is expected to become default behaviour in future.

#553