-
Notifications
You must be signed in to change notification settings - Fork 153
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.
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
Normative: Don't accept Z designators in strings for Plain types #1874
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1874 +/- ##
=======================================
Coverage 95.01% 95.02%
=======================================
Files 19 19
Lines 10940 10949 +9
Branches 1732 1739 +7
=======================================
+ Hits 10395 10404 +9
Misses 530 530
Partials 15 15
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Draft until presented at TC39 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thanks!
(Needs more complete test coverage.) Tests for the normative changes made to Temporal in tc39/proposal-temporal#1874
(Needs more complete test coverage.) Tests for the normative changes made to Temporal in tc39/proposal-temporal#1874
(Needs more complete test coverage.) Tests for the normative changes made to Temporal in tc39/proposal-temporal#1874
This gained consensus at the October TC39 plenary. I am currently working on updating the tests. |
(Needs more complete test coverage.) Tests for the normative changes made to Temporal in tc39/proposal-temporal#1874
9556bca
to
cccb5a3
Compare
This change unearthed that we have some really out of date cookbook examples Maybe we can get #1930 in first and then land this one. |
Accepting this kind of string in Plain types poses a risk when deserializing from databases, as some attach local-time-zone semantics to this kind of string. This could cause user-facing off-by-one-day bugs. Closes: #1751
cccb5a3
to
efe75c0
Compare
In tc39#1874, we removed the ability to parse Z strings with Plain types' `from` methods. This PR explains this change and documents workarounds. The docs for PlainYearMonth and PlainMonthDay (where Z strings are rare) get only minimal text. PlainDate, PlainDateTime, and PlainTime (where Z-string use cases are most likely) get a little more explanation and a short code sample.
Cool! I opened #1942 to describe these changes in the docs. |
In #1874, we removed the ability to parse Z strings with Plain types' `from` methods. This PR explains this change and documents workarounds. The docs for PlainYearMonth and PlainMonthDay (where Z strings are rare) get only minimal text. PlainDate, PlainDateTime, and PlainTime (where Z-string use cases are most likely) get a little more explanation and a short code sample.
Co-authored-by: Philip Chimento <[email protected]>
Since #1874, strings with Z UTC designator are disallowed for Plain types. This was not yet reflected in the manual ISO string generator test.
Since #1874, strings with Z UTC designator are disallowed for Plain types. This was not yet reflected in the manual ISO string generator test.
Tests for the normative changes made to Temporal in tc39/proposal-temporal#1874
Tests for the normative changes made to Temporal in tc39/proposal-temporal#1874
Accepting this kind of string in Plain types poses a risk when
deserializing from databases, as some attach local-time-zone semantics to
this kind of string. This could cause user-facing off-by-one-day bugs.
(Note: this could probably be refactored to have these strings actually be invalid according to the ISO 8601 grammar, but this PR is set up so that could be done separately as an editorial change.)
Closes: #1751