[Y_Y]

It is somewhat ironic that the date reference in use throughout that page is of the form "April 1987”.

I greatly respect the effort to make a well-thought-out timestamp that balances readability and cultural neutrality and versatility across contexts and eras. I try to use at least ISO–8601 timestamps when I can.

It sometimes feels like a losing battle though. Even if a luser can roughly guess what

    1996-12-19T16:39:57-08:00[America/Los_Angeles]

means, it's never going to make it into the UI. The trend is for "About two hours ago" or "Last week". That's fine for the Fuzzy Clock in your task bar maybe, but precise timing is as important as it it unpopular.

I don't know what the answer is here. Maybe a "time reference" object that your interface can interpret dynamically to your preferences and needs?

[crote]

> Even if a luser can roughly guess what $ts means, it's never going to make it into the UI.

It's not intended to. It's designed for standardized machine-to-machine communication, which is currently a mostly unsolved problem for zoned timestamps.

[Y_Y]

I interpret RFC 3339 not to apply exclusively to machine-to-machine communication. Specifically section 5.3 includes the following:

> a balance must be struck between human readability and interoperability.

and

> Internet clients SHOULD be prepared to transform dates into a display format suitable for the locality.

(where SHOULD is used in the RFC 2119 sense equivalent to RECOMMENDED).

[happytoexplain]

Human readability does not mean end user readability. It's good if humans can read it so that programmers/admins can read it, and also end users if they happen to be exposed to it. But for display to end users, it should always be formatted in a localized, naturally readable manner with no concern for machine parsing (which is what the second quote is referring to).