- From: Manu Sporny via GitHub <sysbot+gh@w3.org>
- Date: Sat, 08 Jul 2023 14:49:38 +0000
- To: public-i18n-archive@w3.org
> A challenge of this data type is that it allows values both with (2023-06-15T00:00:00Z or 2023-06-15T00:00:00-08:00) and without (2023-06-15T00:00:00) time zone offsets. Since validFrom and validTo need to be interpreted as timestamp values, the spec should probably require that values without zone offsets be treated as being in the UTC time zone. Yes, that's correct and why we're trying to change to XMLSCHEMA11-2 `dateTimeStamp`, which requires the usage of a timezone offset. We've already seen some examples in the wild that didn't include a timezone offset and thus were being interpreted as local timezone (instead of Zulu timezone). While we have no reports of this blowing up on people in the field, it's only a matter of time until it does, so we're requiring a timezone to be included in all `dateTimeStamp` values (which every date time field uses at present). -- GitHub Notification of comment by msporny Please view or discuss this issue at https://github.com/w3c/i18n-activity/issues/1729#issuecomment-1627367511 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 8 July 2023 14:49:40 UTC