Dates: pros and cons of UTC vs localtime

[brong]

From Chris Newman:

3.8 Date datatype

Are you sure you want to pin the timezone of timestamps to UTC? This potentially loses information.

[cjnewman]

If I'm traveling in Prague, for example, and send an email to someone back in California who knows that's where I live, the timezone offset provides useful information to the recipient (in particular, about when they might expect replies and whether calling me would be a good idea).

Searches are where things get tricky. If a user performs a date-based search, the user would generally prefer to see messages based on the day boundaries in their local timezone. However, if the server doesn't know the end-user's local timezone, then UTC normalization is at least a predictable choice. IMAP got date-based searches wrong.

[filipnavara]

While the time zone offset offers a useful information it is of limited usability. The information is not usually displayed to the end-user unless they specifically look for it in the headers. They are presented with dates converted to their local time zone. Due to overlapping hours during time shift it is also not a deterministic. Arguably that information is already lost in the email headers if the time zone offset is used there, but I believe the same mistake shouldn't be repeated in new specifications.

(Note that there are inevitably some cases in calendaring, where you need to support more than just UTC dates and that has to be represented somehow, but that is a completely separated topic. People expect recurring events to recur in their time zone despite time shifts, so the events are bound to a specified time zone. And there are "floating" events, which are bound to a local time of a place where you currently are, ie. "brush my teeth at 7am".)

[jeffpc]

I couldn't agree more with what @cjnewman said. Having the TZ information available is a very good thing. Whether or not it is displayed is up to the MUA developer (or the user if the display of TZ info is configurable). The addition of TZ in the requests and responses shouldn't appreciably increase the complexity of either the client or the server.

(By the way, is there a reason the time-secfrac is supposed to be omitted?)

[cjnewman]

filipnavara: Numeric timezone offsets are both precise and deterministic (they convert to a specific UTC time). A time becomes precise but non-deterministic when you refer to a future time with a human timezone name; and as you point out, that's a requirement for correct operation of a calendaring system. These are non-deterministic because the mapping from human timezone name (like America/Los_Angeles) to numeric offset is subject to legislative whim. I'm suggesting that JMAP mail should consider using numeric zone offsets (precise and deterministic). The only place where JMAP mail deals with future times is future release (RFC 4865) which already requires use of UTC to avoid the non-deterministic zone mapping problem. I do not believe JMAP mail should use human timezone names for anything.

[neilj]

I do not believe JMAP mail should use human timezone names for anything.

Agreed. These are needed for calendaring, but would just be problematic here.

There are a few things to clarify I think:

• The "date" property on the JMAP Message object is equivalent to the internal date attribute in IMAP. This is only usefully in UTC, since the time is set by the server and the user should not care what time zone the mail server is in.
• I think we need a separate property for a parsed version of the Date header from the email (which can only currently be read via the headers property). We could allow this to be a date that includes a timezone offset rather than mandating UTC; the main disadvantage to this I think is that we don't need this format anywhere else, so we would have to add an extra Type to the specification just for this property. It's questionable whether the information is useful or reliable (do any mainstream clients show the time zone offset to the user?) but I'm not strongly opposed if there's a consensus that this is useful.

Regarding property names, perhaps the current "date" property should be renamed to "receivedAt", and the parsed date from the header be called "sentAt"?