Merge pull request #30 from justingrant/saving-singular

Minor wording updates for DST terms

Author: aphillips

index.html

@@ -201,7 +201,7 @@ <h3 id="definitions">Definitions</h3>
 
  <p class="definition"><dfn class="lint-ignore export">Era</dfn> A grouping within a <a>calendar</a> used to number years. Most eras start with year "1" and count up to the start of the next era. There are some exceptions to this: the Gregorian calendar's era "BCE" counts backwards, with 1 BCE being the year just before 1 CE (1 AD).</p>
 
- <p class="definition"><dfn>Ghost time</dfn> A <a>wall time</a> that can never exist because of time zone or <a>calendar</a> rules. For example, the date `2023-02-29` is a "ghost time" because 2023 is not a leap year in the Gregorian calendar. Similarly, in the `America/Los_Angeles` time zone, the <a>wall time</a> `2:34 a.m.` on the date `2024-03-10` is a "ghost time" because, due to daylight-savings time, the clock skips from `1:59 a.m.` directly to `3:00 a.m.`.</p>
+ <p class="definition"><dfn>Ghost time</dfn> A <a>wall time</a> that can never exist because of time zone or <a>calendar</a> rules. For example, the date `2023-02-29` is a "ghost time" because 2023 is not a leap year in the Gregorian calendar. Similarly, in the `America/Los_Angeles` time zone, the <a>wall time</a> `2:34 a.m.` on the date `2024-03-10` is a "ghost time" because, due to Daylight Saving Time, the clock skips from `1:59 a.m.` directly to `3:00 a.m.`.</p>
 
  <p class="definition"><dfn class="lint-ignore export">Timeline</dfn> In a given chronology, the fixed sequence of moments, measured against the <a>epoch</a>. A datetime value is said to be <em>on the timeline</em> if it is attached to a discrete moment in time. This is a hallmark of incremental time values.</p>
 
@@ -217,7 +217,7 @@ <h3 id="definitions">Definitions</h3>
 
  <p class="definition"><dfn class="link-ignore export">Local Time Offset</dfn> The different (positive or negative) of a given location from <a>UTC</a>. This is usually expressed as an offset in hours and minutes, such as <code>+10:00</code> or <code>-09:30</code>.</p>
 
- <p class="definition"><dfn class="link-ignore" data-lt="summer time|daylight savings time|DST|daylight time">Daylight Savings Time</dfn> Also called <em>summer time</em> or <em>daylight time</em> and abbreviated <em>DST</em>. The practice of advancing clocks to make better use of longer periods of daylight during the summer, so that darkness falls at a later [=wall time=]. Rules around observation (or non-observation) of DST is one feature of a time zone.</p>
+ <p class="definition"><dfn class="link-ignore" data-lt="summer time|daylight saving time|DST|daylight time">Daylight Saving Time</dfn> Also called <em>summer time</em> or <em>daylight time</em> and abbreviated <em>DST</em>. The practice of advancing clocks to make better use of longer periods of daylight during the summer, so that darkness falls at a later [=wall time=]. Rules around observation (or non-observation) of DST is one feature of a time zone.</p>
 </section>
 
 <section>
@@ -255,7 +255,7 @@ <h3>What is a Time Zone?</h3>
 <p>In the modern era, most countries have a single time zone, but a number of larger or more geographically distributed countries have more than one.</p>
 
 <section id="summer-time">
-<h4>Daylight Savings or Summer Time</h4>
+<h4>Daylight Saving or Summer Time</h4>
 
 <p>The concept of "Daylight Saving Time" (DST) or "Summer Time" is used as a way of allowing people more sunlight hours in the evening. Not all regions observe summer time: usually those nearer the equator do not need it. Whether summer time is observed and how it is observed varies by jurisdiction.</p>
 
@@ -274,7 +274,7 @@ <h4>What defines a time zone?</h4>
 
 <p><strong><a>Local Time Offset</a></strong> Time zones are used to compute the offset of <a>wall time</a> from <a>UTC</a>. The local time offset is the difference (positive or negative) between when a given time event is observed in UTC and local time. If all time zones used one-hour offsets, there would be 24 world-wide time zones, ranging between 12 hours before UTC to 11 hours following UTC. However, there are some that use half-hour or even quarter-hour offsets (or even some odd offsets). In addition, some time zones fall outside a single 24-hour span.</p>
 
-<p><strong>Observation of summer time</strong> Some times zones include rules for observing daylight-savings or summer time, while others do not. The observation of summer time is defined by a set of rules that include:
+<p><strong>Observation of summer time</strong> Some times zones include rules for observing DST or summer time, while others do not. The observation of summer time is defined by a set of rules that include:
     <ul>
        <li><strong>Summer time offset</strong> The amount of time added to (or subtracted from) the <a>local time offset</a> when summer time is being observed. Nowadays this is always one hour, but other values are theoretically possible (and have been used historically).</li>
        <li><strong>Starting date</strong> Usually described as a specific date on a specific calendar, such as the "first Sunday in April"</li>
@@ -287,7 +287,7 @@ <h4>What defines a time zone?</h4>
 <p><strong>Adoption Dates</strong> Regions that currently have a specific local time offset and summer time behavior may have had different rules in the past (or plan to adopt new rules in the near future). Correct handling of past time values requires treating such regions as separate time zones.</p>
 
 <aside class="example">
-    <p>Adoption dates can be applied to any of the values that define a time zone, such as the amount of summer time offset and the starting/ending dates or times for summer time. For example, prior to 2007, the United States started daylight-savings time at 2 a.m. on the first Sunday in April for each time zone observing daylight-savings. In 2007, the USA changed the start date and time to 2 a.m. on the second Sunday in March.</p>
+    <p>Adoption dates can be applied to any of the values that define a time zone, such as the amount of summer time offset and the starting/ending dates or times for summer time. For example, prior to 2007, the United States started Daylight Saving Time at 2 a.m. on the first Sunday in April for each time zone observing DST. In 2007, the USA changed the start date and time to 2 a.m. on the second Sunday in March.</p>
 </aside>
 <aside class="example">
     <p>Korea Standard Time and Japan Standard Time currently use the same UTC offset and neither uses summer time. However, Japan abandoned summer time in 1951, while South Korea used it last in 1988, so an application that tracks time values that reach back that far might need to track these time zones separately.</p>
@@ -380,7 +380,7 @@ <h3>Selecting the Time Zone using the Local Time Offset</h3>
 <section id="tz-stability">
 	<h4>Stability of time zones</h4>
 
-	<p>Time zones, their rules, offsets, and observation (or non-observation) of summer time are controlled by a variety of international agreements, as well as national, regional, sub-national, and local governments. This can mean that neighboring areas that might otherwise share a UTC offset, even those with similar latitude (or shared borders) can have differing rules, such as those governing daylight-savings. Sometimes local authorities will change the boundaries of a zone or the offset used by a given region. Or they can make one-time changes to accommodate a special event (such as when hosting the Olympics). The time zone database tracks past changes so that applications can accurately compute <a>wall time</a> for past and future events.</p>
+	<p>Time zones, their rules, offsets, and observation (or non-observation) of summer time are controlled by a variety of international agreements, as well as national, regional, sub-national, and local governments. This can mean that neighboring areas that might otherwise share a UTC offset, even those with similar latitude (or shared borders) can have differing rules, such as those governing Daylight Saving Time. Sometimes local authorities will change the boundaries of a zone or the offset used by a given region. Or they can make one-time changes to accommodate a special event (such as when hosting the Olympics). The time zone database tracks past changes so that applications can accurately compute <a>wall time</a> for past and future events.</p>
 
     <p>Because there are many governing bodies acting independently, the time zone database is not stabilized. New rule changes or updates to historical records are introduced into the database as they are made known (such as due to legislative action). There is no specific release cycle: updates can happen at any time. When changes affect future events, computing systems have to be updated lest their clocks show the wrong local time for a given region or compute the wrong results for events affected by the change.</p>
 </section>
@@ -553,7 +553,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>
 
     <p>Bear in mind that rolling fields forwards or backwards in [=field-based times=] can be tricky. For example, Feburary does not always have the same number of days in it. Or consider the problem of incrementing the month forward by one in the date <code>2011-01-30</code>.</p>
 
@@ -680,9 +680,9 @@ <h3>Handling past or future events</h3>
 	<aside class="example" title="Example of a time zone change affecting a future event" id="certificate-example">
 	   <p>For example, consider an application that defines certificates. Each certificate has a date-time value that is the "start of authority" (<code>validFrom</code>) moment and a date-time value that is the "end of authority" (<code>validUntil</code>) moment.</p>
 
-	   <p>Imagine that Certificate A is generated in the time zone <code>America/Los_Angeles</code>. This time zone has a raw offset from UTC of 8 hours and it currently observes [=daylight savings time=] between a date in March and a date in November. Certificate A is generated with a <code>validUntil</code> value of <code>2035-07-12T12:00:00-07:00</code>, reflecting the observation of DST during the month of July.</p>
+	   <p>Imagine that Certificate A is generated in the time zone <code>America/Los_Angeles</code>. This time zone has a raw offset from UTC of 8 hours and it currently observes [=daylight saving time=] between a date in March and a date in November. Certificate A is generated with a <code>validUntil</code> value of <code>2035-07-12T12:00:00-07:00</code>, reflecting the observation of DST during the month of July.</p>
 
-	   <p>After Certificate A was generated (but before it expires), imagine that the time zone <code>America/Los_Angeles</code> decides to stop observing [=daylight savings time=]. Then imagine a user wishes to generate Certificate B to replace Certificate A when it expires. If the new certificate is valid "from noon on 12 July", it might be serialized as <code>2035-07-12T12:00:00-08:00</code>, because the time zone's offset will not be in DST any longer. Notice that this is one hour later than the actual expiration of Certificate A.</p>
+	   <p>After Certificate A was generated (but before it expires), imagine that the time zone <code>America/Los_Angeles</code> decides to stop observing [=daylight saving time=]. Then imagine a user wishes to generate Certificate B to replace Certificate A when it expires. If the new certificate is valid "from noon on 12 July", it might be serialized as <code>2035-07-12T12:00:00-08:00</code>, because the time zone's offset will not be in DST any longer. Notice that this is one hour later than the actual expiration of Certificate A.</p>
 	</aside>
 
 <section id="past-only-use-case">