Minor wording updates for DST terms #30
Merged
+9
−9
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Daylight Saving Time doesn't have an "s" at the end of Saving. https://en.wikipedia.org/wiki/Daylight_saving_time
✅ Deploy Preview for w3c-timezone ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
aphillips
approved these changes
Jul 25, 2025
index.html
Outdated
| @@ -552,7 +552,7 @@ <h3>Working with mixed representations</h3> | |||
|
|
|||
| <p>[=Incremental time=] and [=field-based time=] differ in the way certain operations work. For example, incremental times can often be directly compared: their integer values determine which is earlier or later. [=Field-based times=] have to be normalized and their individual fields compared.</p> | |||
|
|
|||
| <p>[=Field-based times=] are often optimized to allow for various kinds of adjustments to be made to a value while minimizing the chances for error. For example, to set the date <code>2005-08-30</code> forward by one day, an implementation can add 'one unit' to the "day" field and adjust the day, month, and year fields as appropriate to the calendar system. In incremental time, a similar operation might be performed by incrementing the value by <code>24 hours * 60 minutes * 60 seconds * 1000 milliseconds</code>, which is one "logical day". However, there can be errors when a particular day has more or fewer seconds in it (such as occur during daylight saving transitions) or when the unit has a variable size, such as when adding a month or a year, since those fields have variable numbers of days in them.</p> | |||
| <p>[=Field-based times=] are often optimized to allow for various kinds of adjustments to be made to a value while minimizing the chances for error. For example, to set the date <code>2005-08-30</code> forward by one day, an implementation can add 'one unit' to the "day" field and adjust the day, month, and year fields as appropriate to the calendar system. In incremental time, a similar operation might be performed by incrementing the value by <code>24 hours * 60 minutes * 60 seconds * 1000 milliseconds</code>, which is one "logical day". However, there can be errors when a particular day has more or fewer seconds in it (such as occur during DST transitions) or when the unit has a variable size, such as when adding a month or a year, since those fields have variable numbers of days in them.</p> | |||
There was a problem hiding this comment.
I would keep "daylight saving time" here or at least termify DST (e.g. [=DST=])
There was a problem hiding this comment.
Oh! I naively assumed that it worked like ecmarkup where words are automatically termified if the text matches. I amended the commit to make this change.
Updates usage of DST-like terms to instead use either "Daylight Saving TIme" or "DST" which are the terms in the definitions section.
justingrant
force-pushed
the
saving-singular
branch
from
d65373c to
f954305
Compare
aphillips
approved these changes
Jul 26, 2025
|
Thank you! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I just discovered this document, and I'm so happy it exists! I led the design of JS's new
Temporal.ZonedDateTimeand I'm pleased to see helpful timezone info popping up elsewhere in the web plaform. Thanks for writing it.This PR includes two commits with minor wording suggestions:
Hopefully these suggestions aren't too pedantic!