Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Define legal userland time zone and calendar identifiers #665

Closed
ptomato opened this issue Jun 11, 2020 · 1 comment · Fixed by #1010
Closed

Define legal userland time zone and calendar identifiers #665

ptomato opened this issue Jun 11, 2020 · 1 comment · Fixed by #1010
Assignees
@ptomato
Labels
documentation Additions to documentation non-prod-polyfill THIS POLYFILL IS NOT FOR PRODUCTION USE! spec-text Specification text involved
Milestone
Stable proposal

Comments

@ptomato
Copy link
Collaborator

ptomato commented Jun 11, 2020

Follow up from #638. Previously the definition of what should be parsed as a time zone name was "any string for which IsValidTimeZoneName returns true".

Now that we allow custom time zones, what names should be allowed? Is Etc/🐈 a valid name for a time zone, making 2020-06-11T16:06:23.123+01:23[Etc/🐈] a valid ISO string?
IANA names adhere to the following rules:

Use only valid POSIX file name components (i.e., the parts of names other than /). Do not use the file name components . and ... Within a file name component, use only ASCII letters, ., - and _. Do not use digits, as that might create an ambiguity with POSIX TZ strings. A file name component must not exceed 14 characters or start with -.

Same question for calendar names.
@ptomato ptomato added this to the Stage 3 milestone Jun 11, 2020
@ptomato ptomato mentioned this issue Jun 11, 2020
Merged
4 tasks
@ptomato ptomato mentioned this issue Aug 31, 2020
Closed
@ptomato ptomato modified the milestones: Stage 3, Stable proposal Sep 17, 2020
@ptomato ptomato added documentation Additions to documentation spec-text Specification text involved non-prod-polyfill THIS POLYFILL IS NOT FOR PRODUCTION USE! labels Sep 18, 2020
@ptomato
Copy link
Collaborator Author

ptomato commented Oct 8, 2020

(Calendar names consist of components of between 2 and 8 ASCII alphanumeric characters each, separated by dashes: https://tools.ietf.org/html/bcp47#section-2.1)

@ptomato ptomato self-assigned this Oct 16, 2020
ptomato added a commit that referenced this issue Oct 16, 2020
@ptomato
Define valid calendar IDs
e5ad6bd 
A valid calendar ID according to BCP 47 is a number of components
consisting of 2 to 8 ASCII alphanumerics each, joined by dashes. Add this
to the grammar and enforce it in custom calendars.

See: #665
ptomato added a commit that referenced this issue Oct 16, 2020
@ptomato
Define valid time zone IDs
992acd6 
A valid calendar ID according to the tzdata documentation is a number of
components consisting of 1 to 14 ASCII alpha characters, dashes, dots, or
underscores each, joined by slashes. `.`, `..`, or any string starting
with a dash are not valid components. Add this to the grammar and enforce
it in custom time zones.

Etc/GMT time zones are an exception, as they may contain + or digits.
These are valid for parsing, but not for custom time zones.

See: #665
@ptomato ptomato mentioned this issue Oct 16, 2020
Merged
ptomato added a commit that referenced this issue Oct 16, 2020
@ptomato
Define valid calendar IDs
9e2c083 
A valid calendar ID according to BCP 47 is a number of components
consisting of 2 to 8 ASCII alphanumerics each, joined by dashes. Add this
to the grammar and enforce it in custom calendars.

See: #665
ptomato added a commit that referenced this issue Oct 16, 2020
@ptomato
Define valid time zone IDs
5f3b1d9 
A valid calendar ID according to the tzdata documentation is a number of
components consisting of 1 to 14 ASCII alpha characters, dashes, dots, or
underscores each, joined by slashes. `.`, `..`, or any string starting
with a dash are not valid components. Add this to the grammar and enforce
it in custom time zones.

Etc/GMT time zones are an exception, as they may contain + or digits.
These are valid for parsing, but not for custom time zones.

See: #665
ptomato added a commit that referenced this issue Oct 17, 2020
@ptomato
Define valid calendar IDs
ce14335 
A valid calendar ID according to BCP 47 is a number of components
consisting of 2 to 8 ASCII alphanumerics each, joined by dashes. Add this
to the grammar and enforce it in custom calendars.

See: #665
ptomato added a commit that referenced this issue Oct 17, 2020
@ptomato
Define valid time zone IDs
667e757 
A valid calendar ID according to the tzdata documentation is a number of
components consisting of 1 to 14 ASCII alpha characters, dashes, dots, or
underscores each, joined by slashes. `.`, `..`, or any string starting
with a dash are not valid components. Add this to the grammar and enforce
it in custom time zones.

Etc/GMT time zones are an exception, as they may contain + or digits.
These are valid for parsing, but not for custom time zones.

See: #665
@ptomato ptomato mentioned this issue Sep 14, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ptomato ptomato

Labels
documentation Additions to documentation non-prod-polyfill THIS POLYFILL IS NOT FOR PRODUCTION USE! spec-text Specification text involved
Projects
None yet
Milestone
Stable proposal
Development

Successfully merging a pull request may close this issue.

Define valid calendar and time zone IDs tc39/proposal-temporal
1 participant
@ptomato