Merge pull request w3c#10 from aphillips/gh-pages

Add SEDATE mention and define floating/unfloating time value

index.html

@@ -371,6 +371,7 @@ <h3>Time Zones</h3>
 <section>
 <h3>Serializations</h3>
 
+<p class=issue>Some of the serializations in this section are not currently part of any standard. Work at the IETF on <a href="https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/">SEDATE</a> might address this gap. Other standards, such as XMLSchema might be affected.</p>
 <table>
 	<thead>
 		<tr>
@@ -448,7 +449,7 @@ <h2>Use Cases</h2>
 <section>
 	<h3>Timestamps</h3>
 
-	<p class=advisement>Use the <code>Instant</code> type for timestamp values.</p>
+	<p class="advisement">Use the <code>Instant</code> type for timestamp values.</p>
 
 	<p>If your application can accurately generate incremental and/or field-based times based on UTC and the events are not tied to specific local time, all that is needed is the timestamp value itself. That is, if your application never needs to recover what the actual wall time was when event occurred and only cares about relative ordering of events. For example, if you merge log files from many machines together or if you are recording events in a log, a timestamp is perfectly adequate. For these types of time events, an Instant is sufficient.</p>
 
@@ -472,16 +473,16 @@ <h3>Handling past or future events</h3>
 <section>
 	<h3>Past-only Events</h3>
 
-	<p class=advisement>You SHOULD use <code>ZonedInstant</code> type for past-only events.</p>
-	<p class=advisement>You MAY use <code>ZonedInstant</code>, <code>ZonedLocalDateTime</code> or <code>ZonedOffsetDateTime</code> types for past events.</p>
+	<p class="advisement">You SHOULD use <code>ZonedInstant</code> type for past-only events.</p>
+	<p class="advisement">You MAY use <code>ZonedInstant</code>, <code>ZonedLocalDateTime</code> or <code>ZonedOffsetDateTime</code> types for past events.</p>
 
 	<p>For applications that deal only with events that occurred in the past (with no future events) and for which you need to know what the wall time was, the time zone of the event may be necessary additional data. Once an event is in the past, its relationship to incremental time becomes fixed and the rules for generating wall time remain static essentially forever. You might still need to know that an event occurred at <code>10:00</code> rather than at <code>14:00</code> local time. At a minimum, the <a>local time offset</a> is necessary, although knowing the complete time zone is necessary for some applications. Knowing the specific time zone allows one to reconstruct the time and its relationship to other wall times.</p>
 </section>
 
 <section>
 	<h3>Past and Future Events</h3>
 
-	<p class=advisement>You SHOULD use <code>ZonedInstant</code> type if your application can have events in the future.</p>
+	<p class="advisement">You SHOULD use <code>ZonedInstant</code> type if your application can have events in the future.</p>
 
 	<p>If your application deals with both past and future events (for example, if you have a calendar or a meeting schedule), you’ll need additional time zone information to ensure proper time computation. At a minimum you will need the time zone, not merely an offset from UTC. This is because a future event's wall time depends on time zone related information, such as DST transitions. One issue with future events is that time zone rules can change from time to time and these may require an application to update affected data records in order to meet user’s expectations. This is because many systems actually store the time portion of the value as an incremental time and the incremental time needs to be changed if the wall time offset from UTC has been altered.</p>
 </section>
@@ -505,6 +506,16 @@ <h3>Floating Time Values</h3>
 	<h3>Floating and Unfloating Time</h3>
 
 	<p>Sometimes a <a>producer</a> will emit a <a>floating time</a> value when the <a>consumer</a> expects or requires an <a>incremental time</a> value. In other cases, a <a>consumer</a> might need to convert a local or otherwise incremental time value into a floating date or time.</p>
+
+	<p class="definition"><dfn data-lt="lint-ignore export">Floating a time value</dfn> means to remove the value from the timeline by deleting any associated time zone and zone offset information from the value.</p>
+
+	<p>One common reason to float a value is if the data type used to collect or process the value is an incremental type but the value isn't. For example, if you received a user's birth date as a `Date` object. Removing the time zone or offset makes it easier to format the value later without the field values changing in correctly.</p>
+
+	<p class="definition"><dfn  data-lt="lint-ignore export">Unfloating a time value</dfn> means to attach a floating time value to the timeline by adding a time zone or zone offset to the value.</p>
+
+	<p>One common reason to unfloat a value is that the serialized value might not contain an offset but the value needs to be compared to other incremental values or displayed to the user in local time.</p>
+
+	<p class="advisement">Values received without a time zone or zone offset SHOULD generally be treated as if they are in UTC. Specifications SHOULD provide guidance on how to handle these values. Implementations MAY use some other value for the offset, such as local time, but only if there is a good reason to do so.</p>
 </section>
 </section>