MSC3160: Message timezone markup

[bwindels]

Rendered

[uhoreg]

The equivalent local time may depend on the date that the time is for. For example, your "9am tomorrow" may be a different time for me from your "9am next Monday" if my daylight saving time change happens in between. (Yay, time is fun.)

[bwindels]

Good point, will remove this potential issue then.

[bwindels]

Hmm, thinking about it further, I can see how this would a problem with symbolic timezone names, but here I propose to use timezone offsets, which are assumed to be the offset at the referred date for the sender. Makes me wonder if we should rather use symbolic timezone names though, as it migth be hard to calculate an offset for the future taking into account DST changes, ... like this? OTOH, an offset doesn't require you to have a valid list with timezones, although most standard libraries should help you with that?

[KitsuneRal]

First, you'll have to deal with symbolic timezone names for data entry anyway because many people don't even know/remember the offset of their current timezone; and changing the data in the profile as suggested in another place won't help with "world citizens" who live (ok, lived and will live, given the situation) across three different timezones in a single week (I know a few such people). Second, even with the current zone set in the profile or resolved by the browser, sitting in Singapore at 23:00 local time the sender may plan a day in London the next day, writing "let's meet at 7:00 GMT at the airport" - he doesn't even think of using his current local (or GMT) date for that. I'd probably just leave the case of time-without-date alone.

[ara4n]

another option could be to default the TZ from the user’s profile (once we have profiles as rooms) if the browser is reporting UTC.

[erkinalp]

default the TZ from the user’s profile

That will fail if the user account in question has multiple identities with different profile rooms each, and the room in question is associated with none of those identities.

[ara4n]

irritatingly the spec currently says:

The strongly suggested set of HTML tags to permit, denying the use and rendering of anything else, is...

which we should tweak to clarify that unrecognised tags like time are ignored (but the contents should be rendered as if the tag didn’t exist, rather than not rendered at all).

[ara4n]

This is the bit of the proposal which scares me - I’m having problems imagining nice UI for this (at least in a manner which has widespread client support). Doing i18n friendly NLP on autodetecting times is hard and could pull in a tonne of dependencies (unless your OS provides something like NSDataDetector). Alternatively expecting users to press an insert timestamp button whenever they want to write a time seems ambitious.

But if it can be proven to work in the wild then \o/ :)

[dkasak]

This is basically my foremost complaint about this MSC as well. It seems like it will be very hard to accommodate ergonomic entry for these inline datetime specifications. A proper standalone calendar event type seems like the better solution for the problem this is trying to solve.

[KitsuneRal]

I can point to Todoist as a cross-platform set of applications that does NLP of dates and times (only in one language, the user's current one) reasonably well, including things like "next Thursday" etc.; unfortunately, the code is not open-sourced, so it's merely a confirmation that it's possible. Now they are in business for 5+ years and are still fixing all kinds of corner cases (both false-positive and false-negative ones) through all this time; so this reference is rather an advice to probably not try to do that, unless it is to be a key competitive advantage of Matrix (it is for Todoist), which I don't anticipate.

Also, in my (distributed across 4 locales) current team we actively use "your time" to define the timezone (as in "let me call you at 9am tomorrow your time"). You just cannot translate that to anything without prior knowledge of the receiver's timezone.

[kevincox]

I don't share the concern here. It is hard to do automatically, and most clients won't do it. But that is fine, we can leave this to the fancier clients, it isn't a required feature for communication. However I can see a lot of clients putting in a "insert time" button which defaults to your current time zone and shares it out. If people are talking with people in other time zones they will find this button useful enough to reach for when they have an important time to make sure everyone agrees one. Most importantly it is easy for the receiver to implement. Furthermore this is a really easy feature to implement for bots and similar where it may have the most value anyways (me and my friends generally know each other's timezone but I probably don't know what timezone that bot meant when it sent me the message and it probably doesn't know mine to format it for me).

[kegsay]

A cautionary tale about timezones: https://www.youtube.com/watch?v=-5wpm-gesOY

I strongly recommend that we do not mess with timezones at all and do not merge this MSC. The UI proposes hyperlinking text like "3pm tomorrow" in a <time> tag which contains the time + timezone. If we absolutely must do this I would much prefer if the onus was on the client to convert "3pm tomorrow" to the equivalent unix timestamp then send that, which then puts the onus on the receiver to convert back to a date/time.

[tulir]

convert "3pm tomorrow" to the equivalent unix timestamp then send that

Isn't that essentially what's proposed here, except it's an ISO 8601 timestamp instead of Unix?

[kegsay]

Why wouldn't we use unix timestamps as-is as per everything else in Matrix? E.g Devices last_seen_ts, notification ts?

[tulir]

The HTML spec doesn't allow unix timestamps in the datetime attribute, so we'd probably have to use a custom attribute for that.

[Cadair]

I think the sending client should convert to a reference time, ISO 8601 UTC is just as good a reference as unix (better in many ways, as you could display it to a human).

[KitsuneRal]

To begin with, I'd appreciate having that functionality in Matrix. That said, it should be scoped as narrow as possible because it's all too easy to slip into the rabbit hole described in the video Kegan linked to: maybe just allow to enter (in a very controlled way, with validation etc.) the date in one timezone so that another party could have a facilitating control to convert it to another timezone. Any kind of freeform text processing, resolving timezones from whatever the context is there is very precarious from my perspective. Basically, just specify time element with datetime attribute as the way to encode a particular timepoint, and that's it. More below.

[KitsuneRal]

I can point to Todoist as a cross-platform set of applications that does NLP of dates and times (only in one language, the user's current one) reasonably well, including things like "next Thursday" etc.; unfortunately, the code is not open-sourced, so it's merely a confirmation that it's possible. Now they are in business for 5+ years and are still fixing all kinds of corner cases (both false-positive and false-negative ones) through all this time; so this reference is rather an advice to probably not try to do that, unless it is to be a key competitive advantage of Matrix (it is for Todoist), which I don't anticipate.

Also, in my (distributed across 4 locales) current team we actively use "your time" to define the timezone (as in "let me call you at 9am tomorrow your time"). You just cannot translate that to anything without prior knowledge of the receiver's timezone.

[KitsuneRal]

First, you'll have to deal with symbolic timezone names for data entry anyway because many people don't even know/remember the offset of their current timezone; and changing the data in the profile as suggested in another place won't help with "world citizens" who live (ok, lived and will live, given the situation) across three different timezones in a single week (I know a few such people). Second, even with the current zone set in the profile or resolved by the browser, sitting in Singapore at 23:00 local time the sender may plan a day in London the next day, writing "let's meet at 7:00 GMT at the airport" - he doesn't even think of using his current local (or GMT) date for that. I'd probably just leave the case of time-without-date alone.

[daenney]

I'm thinking we might want to use a timezone identifier instead of an offset from UTC. Offsets from UTC are only valid at one point in time, whereas the timezone identifier lets you reliably figure out when an event is actually happening. This can be especially confusing around the summer/winter time transitions when Europe and the US are offset differently from each other too.

If I want to plan a meeting for "9am next week Monday", I want that meeting to happen at 9am that time in that timezone. If a DST transition happens between when I typed that message and the event, I still want it to be at 9am, not one hour earlier or later. The offset from UTC loses that information whereas if we have a timezone identifier we can do the right thing.

[KitsuneRal]

Timezone identifiers are different between daylight saving and non-daylight-saving shifts (GMT/BST, ET/EDT etc.). Offsets allow to specify exactly the timepoint, rather than a symbolic identification subject to further interpretation. These offsets are not for human entry though, they are for payloads on the wire. What you describe is achieved by converting the local time to ISO 8601 time spec on the sender side, taking into account whether the daylight saving is on or off on the target date.

[daenney]

I should have specified I meant IANA tz/zoneinfo identifiers, and not CE(S)T style identifiers. Europe/Amsterdam for example doesn't change based on whether DST is active.

[daenney]

What you describe is achieved by converting the local time to ISO 8601 time spec on the sender side, taking into account whether the daylight saving is on or off on the target date.

Yup, that works. But I think we should specify that more clearly in that case. Because right now that's ambiguous in the spec, so it could end up with a client picking the current offset of the user instead of the offset on the target date.

[KitsuneRal]

Right, this is implied by the format examples use; but not specified clearly.

[kevincox]

It is worth noting here that this doesn't account for timezone definition changes. If I say "Let's meet at 2086-05-13 14:30 America/Toronto" my client would be force to convert this into something like 2086-05-13T18:30-0400. However in 2025 (hopefully) the Canadian government decides that there will be no more daylight savings time. Matrix clients will now assume that this time is 2086-05-13 15:30 America/Toronto which is probably not what the user meant.

This is likely acceptable error for messages that tend to have a short useful life. However it is worth considering some of the benefits of actually including the full time zone specifier in the message.

However there is another use case which may be more relevant. If a client wants to do something such as rescheduling an event or proposing a new time they will want to know the source time zone. If you are near a Daylight Savings boundary you will need to know the sender's actual time zone if you want to reschedule that. For example am I using America/Atikokan or America/Toronto? They both look like -05:00 in February! Similar issues for a "do this again next week" button or anything of the sort.

[deepbluev7]

If the timezones change (by government action or whatever), I would assume the meeting data to change too. You probably still want to meet at the same UTC offset, but your local time will now render differently.

[daenney]

You probably still want to meet at the same UTC offset, but your local time will now render differently.

I doubt that's what people would expect. When you schedule things from a human perspective at "9am on day X" you mean 9am on that day, whatever timezone/offset happens to be in effect on that day. Having your meeting suddenly be at 8:38am because the timezone changed likely means you'll miss the start of the meeting because in your brain you scheduled it for 9am. People generally don't expect meeting times to move b/c of things like DST transitions or changes to their local timezone.

If your government changes your timezone, the bank is still going to open at 10:00 and close at 16:00 in that new timezone, it's not going to move its opening hours.

[daenney]

In these cases time will have to change for someone, but I would expect it to adhere to the timezone of the creator of the event which would mean needing to know the timezone and not just the calculated offset on that day at the time the event was created.

But the most likely outcome for events that are scheduled weeks to months in advance is that someone will create a calendar invite for it instead, which should ensure the right thing happens. So it might not be worth solving that in Matrix instead, though it does potentially make for inaccurate time in the message history.

[kevincox]

I love the feature. I regularly scheduling things with people cross timezone and I'm blown away that no chat app (that I have used) has a good tool for this.

[kevincox]

It is worth noting here that this doesn't account for timezone definition changes. If I say "Let's meet at 2086-05-13 14:30 America/Toronto" my client would be force to convert this into something like 2086-05-13T18:30-0400. However in 2025 (hopefully) the Canadian government decides that there will be no more daylight savings time. Matrix clients will now assume that this time is 2086-05-13 15:30 America/Toronto which is probably not what the user meant.

This is likely acceptable error for messages that tend to have a short useful life. However it is worth considering some of the benefits of actually including the full time zone specifier in the message.

However there is another use case which may be more relevant. If a client wants to do something such as rescheduling an event or proposing a new time they will want to know the source time zone. If you are near a Daylight Savings boundary you will need to know the sender's actual time zone if you want to reschedule that. For example am I using America/Atikokan or America/Toronto? They both look like -05:00 in February! Similar issues for a "do this again next week" button or anything of the sort.

[kevincox]

I don't share the concern here. It is hard to do automatically, and most clients won't do it. But that is fine, we can leave this to the fancier clients, it isn't a required feature for communication. However I can see a lot of clients putting in a "insert time" button which defaults to your current time zone and shares it out. If people are talking with people in other time zones they will find this button useful enough to reach for when they have an important time to make sure everyone agrees one. Most importantly it is easy for the receiver to implement. Furthermore this is a really easy feature to implement for bots and similar where it may have the most value anyways (me and my friends generally know each other's timezone but I probably don't know what timezone that bot meant when it sent me the message and it probably doesn't know mine to format it for me).

[kevincox]

I'm confused. The clients shouldn't be parsing the freeform text in the body but the RFC 3339 timestamp in the datetime attribute.

[kevincox]

We really need to get this section renamed to "Security and Privacy Considerations"

Users may not realize that they are revealing their time zone (or UTC offset) which reveals to something about their location. It is up to clients to inform the users of what they are sharing and possibly provide an option to avoid sharing this information (for example by sending the timestamp in UTC).

[robintown]

Is this right? Looking at https://developer.mozilla.org/en-US/docs/Web/HTML/Element/time I see "a valid time string (e.g. 14:54)" as a valid format for datetime.