Merge 9be599c156 into ecf996389f

proposals/3160-message-timezone-markup.md

@@ -0,0 +1,80 @@
+# MSC3160: Attach timezone metadata to time information in messages
+
+When communicating across timezones, you sometimes want to agree on a time with
+others, for example when to have a meeting. If somebody says "let's meet at 8pm"
+, everybody else in the room has to think in what timezone the other person is,
+and work out the math in their head how that relates to their timezone,
+if different.
+
+Luckily, computers are great at math, and so to facilitate this, clients could 
+allow to represent a point in time with special markup in a message,
+adding the timezone of the sender. The clients of the other users in the room
+can then depending on their local timezone work out the math and render
+the point in time in the timezone of the user.
+
+## Proposal
+
+For events of type `m.room.message` with `msgtype` of `m.text` and `format` of 
+`org.matrix.custom.html` in the `content` field, the `formatted_body` field 
+supports containing the
+[`<time>` element](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/time)
+to annotate text describing a point in time with the timezone of the sender.
+Here is an example:
+
+```json
+{
+    "type": "m.room.message",
+    "content": {
+        "msgtype": "m.text",
+        "format": "org.matrix.custom.html",
+        "formatted_body": "Shall we have a quick call at <time datetime=\"2021-04-30T09:00-0200\">9am tomorrow</time>?"
+    }
+}
+```
+
+The `datetime` attribute should always contain a timezone, which is not required
+ by HTML. We should probably also only allow one specific format,
+ as opposed to HTML.
+ 
+No other attributes are allowed on the `<time>` element.
+
+### Possible user interface
+
+Clients could either detect when the user writes something that looks like
+a timestamp and either automatically wrap it in a `<time>` element, or propose
+to do so. Alternatively, clients could have a time button in the composer
+formatting options that allows to add a time with a dialog, requiring less
+sophisticated time pattern detection while typing.
+
+When rendering an `<time>` element, clients could render it in a special way,
+and allow to interact with it to show the time in the timezone of the sender,
+or any other timezone.
+
+## Potential issues
+
+For web clients, Firefox always
+[reports the local timezone to be UTC](https://bugzilla.mozilla.org/show_bug.cgi?id=1330890)
+when "resist fingerprinting" is on. Web clients would therefore need to at
+least confirm the detected timezone with the user to ensure it does not get
+sent with a different timezone than the user is actually in and create
+a whole new level of confusion.
+
+The `datetime` attribute in HTML does not allow to just specify a time of day
+without specifying the day, which could be nice to have. In that case, clients
+could just use the current day. It might create confusion though if the sender
+didn't mean to explicitly communicate a day.
+
+## Alternatives
+
+Have a custom attribute (`mx-timezone-offset`) and parse the text in the `time`
+element to convert it. Having a machine readable version of the timestamp has
+the advantage that clients don't need to agree how to read the freeform time
+text in the body.
+
+## Security considerations
+
+None I can think of.
+
+## Unstable prefix
+
+Not needed given the time element is already part of html?