W3C home > Mailing lists > Public > public-i18n-archive@w3.org > April to June 2022

[i18n-activity] Registration information time zone handling (#1523)

From: Addison Phillips via GitHub <sysbot+gh@w3.org>
Date: Thu, 28 Apr 2022 19:20:15 +0000
To: public-i18n-archive@w3.org
Message-ID: <issues.opened-1219168952-1651173613-sysbot+gh@w3.org>
aphillips has just created a new issue for https://github.com/w3c/i18n-activity:

== Registration information time zone handling ==
## Proposed comment Registration Information

The fields `created`, `modified`, `expires`, and `retrieved` use the XML Scheme data type `dateTime`. This type can be serialized either with or without a _local time offset_. Values without a local time offset are [floating time](https://w3c.github.io/i18n-glossary/#def_floating_time) values that are not tied to a specific instant.

In most cases, using a floating time value for a moment in the past is not particularly harmful. However, the field `expires` should always be tied to a specific incremental moment on the timeline. Otherwise consumers of the value may continue to use an expired service for up to 26 hours after the actual expiration.

To combat this problem without adding a lot of complexity to the spec, I would suggest adding text that recommends `dateTime` values always include the offset with a strong bias towards using UTC (i.e. `2021-04-28T19:16:00Z` is preferred to `2021-04-12:16:00-07:00`). In addition, I would require that `dateTime` values not accompanied by an offset be treated as being in UTC (i.e. `2021-04-28T00:00:00` is identical to `2021-04-28T00:00:00Z`) so that there is no ambiguity about expiration. A different way to address this issue is to use RFC3339 `date-time` instead of the XMLSchema type.

## Instructions: 

This follows the process at https://w3c.github.io/i18n-activity/guidelines/review-instructions.html

1. Create the review comment you want to propose by replacing the prompts above these instructions, but **LEAVE ALL THE INSTRUCTIONS INTACT** 

2. Set a label to identify the spec: this starts with s: followed by the spec's short name. If you are unable to do that, ask a W3C staff contact to help.

3. Ask the i18n WG to review your comment.

4. After discussion with the i18n WG, raise an issue in the repository of the WG that owns the spec. Use the text above these instructions as the starting point for that comment, but add any suggestions that arose from the i18n WG. In the other WG's repo, add an 'i18n-needs-resolution' label to the new issue. If you think any of the participants in layout requirements task force groups would be interested in following the discussion, add also the appropriate i18n-\*lreq label(s).

5. Delete the text below that says 'url_for_the_issue_raised', then add in its place the URL for the issue you raised in the other WG's repository. Do NOT remove the initial '§ '. Do NOT use \[...](...) notation – you need to delete the placeholder, then paste the URL.

6. Remove the 'pending' label, and add a 'needs-resolution' tag to this tracker issue. 

7. If you added an \*lreq label, add the label 'spec-type-issue', add the corresponding language label, and a label to indicate the relevant typographic feature(s), eg. 'i:line_breaking'. The latter represent categories related to the Language Enablement Index, and all start with i:.

8. Edit this issue to **REMOVE ALL THE INSTRUCTIONS & THE PROPOSED COMMENT**, ie. the line below that is '---' and all the text before it to the very start of the issue.


**This is a tracker issue.** Only discuss things here if they are i18n WG internal meta-discussions about the issue. **Contribute to the actual discussion at the following link:**

§ url_for_the_issue_raised

Please view or discuss this issue at https://github.com/w3c/i18n-activity/issues/1523 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 28 April 2022 19:20:16 UTC

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 18:09:47 UTC