Including Timezones with Events?

ActivityPub
1

Hey,

So I’m looking into how event stuff is done in ActivityPub, and I see start/end times can be set.

So, you get the start/end times with an hours offset to UTC.

However, under certain circumstances, this may not be enough to store and show it correctly. Namely, when the timezone rules change.

(Other circumstances this becomes really important is if someone wants to set up an event that recurs weekly across a DST change - but that might be less important for ActivityPub use cases?)

Looking at a real example - https://test.mobilizon.org/@relay/outbox - this just sends time in UTC. I can’t see anything in there that would tell me what timezone that should be.

Anyone else looked at this?

2

Here are some blog posts that explain in really quite a lot of detail (you have been warned) the problems with just storing UTC:


3

The xsd:dateTime syntax, which I believe is the same as ISO-8601, also affords for describing the time zon if you really want to: https://www.w3.org/TR/xmlschema-2/#dateTime-timezones

With that said, the strings sort nicer if services normalize them to UTC (if possible) before rendering. That’s just a nice-to-have, though. The spec for activitypub, activitystreams2, xsd:dateTime all dont’ require you to use UTC.

4

Am I missing something, but does section 3.2.7.3 only allow for specifying timezones as a plus or minus hours offset? Unfortunately, for some use cases that is not good enough.

To dig into why, check out https://derickrethans.nl/storing-date-time-in-database.html - it starts with

Firstly let me explain why storing a UTC offset is not adequate at all for doing any sort of calculations. Right now (March 25th, 2010), Montreal is on the same time as Santiago (in Chile) with both a UTC offset of -4 hours.

and goes into a very detailed example from there.

Sure, the app should present information all in one time zone to the user for a nice user experience, but to me that’s a different issue - the data exchange should be actually useful first, and it looks like it’s not really?

5

You should take this up with the Internet Engineering Task Force, International Standard Organization, or people involved with W3C’s XML Activity that created xsd:dateTime.

A lot of the internet uses this data exchange format. If your suggestion would improve its completeness, it should be easy to get a +1 from someone involved in its creation. If that endorsement proves hard to secure, you’ll probably learn something along the way.

6

If you’re worried that due to xsd:dateTime's completeness, there are activities you want to describe but can’t in valid ActivityStreams 2.0, I’d encourage you to describe a more expressive vocabulary for describing dates. e.g. instead of as2:created’s range being only xsd:dateTime, you could author a proposal to extend the range to allow (example):

{
  "type": "jarofgreen@socialhub.activitypub.rocks/datetime",
  "iso8601": "2010-03-25T23:03:00.000Z",
  "nanoSecondsOffset": -10,
}

This would help clarify which dateTimes you would like to express but don’t think that ISO8601 is sufficient for.

7

It’s definitely useful, lol. It’s kind of on each of us to describe exactly what we want to use it for.