You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
"It is important to note that" in section 2.3 #701
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?
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.
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.
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.
Activity
trwnh commentedon Apr 17, 2026
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 commentedon May 15, 2026
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:
Or we could just refer to RFC 3339 entirely and remove the ABNF from this section.
evanp commentedon May 15, 2026
Another option is just noting that the type of datetime values is xsd:dateTime, so check that for valid values.
trwnh commentedon Jun 5, 2026
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.
Fix: time offsets vs time zones uses better wording
trwnh commentedon Jun 5, 2026
PR #768 has been created for this issue.
activitystreams/core/index.html
Lines 434 to 441 in 669f443
TallTed commentedon Jun 8, 2026
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.