"It is important to note that" in section 2.3

[evanp]

It is important to note that the time-offset component does not correlate to time-zones, and while times that include the time-offset component work well for timestamps, they cannot be reliably converted to and from local "wall times" without additional information and processing.

Is this a requirement, or a word to the wise? Is there a better phrasing to make it more clear, either using RFC 2119 language, or something more clearly non-normative?

[trwnh]

This sounds like a cautionary statement and not a requirement. Essentially, a "time zone" and a "time zone offset" are two completely different things. Mechanisms like DST (Daylight Saving Time) change the time zone offset (scalar number) for a given time zone (logical/geographical region).

Maybe we could explicitly mention this? Give an example of a UTC datetime, an example of an offset datetime, and an example of an offset changing when DST is in effect. It could be a green callout box / non-normative note.

[evanp]

I feel like describing the conversion of time offset to timezone is out of scope for Activity Streams, but maybe we could have something this simple:

The time-offset component cannot reliably be converted to a timezone without additional information.

Or we could just refer to RFC 3339 entirely and remove the ABNF from this section.

[evanp]

Another option is just noting that the type of datetime values is xsd:dateTime, so check that for valid values.

[trwnh]

Per #331 I think removing this entirely is not well-advised, since it was added explicitly to reduce confusion, upon horizontal request by the i18n WG.

[trwnh]

PR #768 has been created for this issue.

activitystreams/core/index.html

Lines 434 to 441 in 669f443

	<p class="note" title="Avoiding common confusion between time offsets and time zones">
	The `time-offset` component correlates to a time offset from UTC, which is
	not the same as a "time zone". Applications cannot reliably convert
	time offsets to time zones without additional information and processing,
	such as knowing when daylight saving rules are in effect for certain localities,
	as well as the history of legislation which affects historical start and end times
	for daylight saving rules.
	</p>

[TallTed]

This is good. Similar reminders should be placed anywhere date/times are stored, because many people think UTC± are universal values and universally understood. The hazard involved is regularly observable in W3C meetings which are sometimes pinned to ET, and sometimes pinned to EDT or EST, and sometimes pinned to CET, and sometimes pinned to GMT, and sometimes pinned to UTC±, etc., etc. Reinventing this conversion wheel is fraught with peril, and I cannot recommend it to anyone.