1146956 - Datetime format should be self-evident, not lossy

Status: RESOLVED FIXED

(Socorro :: Webapp, task)

Description

[Adrian Aichner [:anaran]]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150323030203

Steps to reproduce:

Webapp? That's a website, not a webapp, right?

Now to the main point:
Looking through my own reports I had trouble interpreting the date-times presented.

See
https://crash-stats.mozilla.com/report/index/e7bbebd0-8536-4f33-b51f-5608e2150324



Actual results:

Date Processed	2015-03-24 15:02:18.034930
Uptime	16113
Last Crash	32610 seconds before submission
Install Age 	18118 since version was first installed.
Install Time 	2015-03-23 14:57:41


Expected results:

The formatting presented is lossy, aside from a small hint in the footer, stating "All dates are UTC".

This doubt for first-time visitors missing the context information in the footer could be removed with one extra character by using JSON format.

The current format is not parsable for a reason:
new Date('2015-03-23 14:57:41')
Invalid Date

While 2015-03-23T14:57:41Z may be a little less readable for humans, it is an exact representation and parsable:

new Date('2015-03-23T14:57:41Z')
Date 2015-03-23T14:57:41.000Z

Not a bad choice for a site focusing on data analysis.

Comment 1

[Robert Kaiser]

I do not agree to useing non-human-readacble dates (and yes, that's what I consider the requested variant)

Comment 2

[Peter Bengtsson [:peterbe]]

On air.mozilla.org we use...:

   <time datetime="2015-03-23T20:00:00+00:00">03/23/2015 20:00 UTC</time>

which a piece of jQuery converts automatically to "3 days ago" or "16 minutes ago". 

We could consider a more human-friendly date format that mentions the timezone in a human-friendly format. E.g. "03 Apr 2015 14:54 UTC". What do you think about that?


Why do you need to parse the dates anyway? Ideally, only your eyes need to parse them :)

Comment 3

[Robert Helmer [:rhelmer]]

I agree, ISO 8601 style dates are not very human friendly.

(In reply to adrian.aichner from comment #0)
> While 2015-03-23T14:57:41Z may be a little less readable for humans, it is
> an exact representation and parsable:

If you want something parseable, we provide an API:
https://crash-stats.mozilla.com/api/

The crash-stats site itself is intended for human consumption.

Comment 4

[Robert Helmer [:rhelmer]]

(In reply to Peter Bengtsson [:peterbe] from comment #2)
> We could consider a more human-friendly date format that mentions the
> timezone in a human-friendly format. E.g. "03 Apr 2015 14:54 UTC". What do
> you think about that?


This seems totally reasonable, makes timezone immediately clear.

Comment 5

[Robert Kaiser]

(In reply to Peter Bengtsson [:peterbe] from comment #2)
> We could consider a more human-friendly date format that mentions the
> timezone in a human-friendly format. E.g. "03 Apr 2015 14:54 UTC". What do
> you think about that?

That would sound fine. That said, if we add "UTC" here explicitly, we'd need to add it everywhere we use times or dates, and that's a lot of places in the UI.

Comment 6

[Adrian Aichner [:anaran]]

My main concern is that the date times can be interpreted correctly immediately, even when quoted a bit out of context, without hunting for further information. I don't need the API, the parsing-argument was just a blunt attempt to defend JSON or ISO strings.

Adding a timezone identifier in any of the existing standard ways would all be fine by me.

Comment 7

[Adrian Aichner [:anaran]]

(In reply to Robert Kaiser (:[e-mail]) from comment #5)
> (In reply to Peter Bengtsson [:peterbe] from comment #2)
> > We could consider a more human-friendly date format that mentions the
> > timezone in a human-friendly format. E.g. "03 Apr 2015 14:54 UTC". What do
> > you think about that?
> 
> That would sound fine. That said, if we add "UTC" here explicitly, we'd need
> to add it everywhere we use times or dates, and that's a lot of places in
> the UI.

Strange that even date.toUTCString() produces "GMT" instead of "UTC", but that should be a minor issue.

It also loses the fractional second component which is shown, e.g. for
Date Processed	2015-03-24 15:02:18.034930

So adding a " UTC" suffix to the ISO-like style used right now sounds like a good idea to me too.

Comment 8

[Will Kahn-Greene [:willkg] ET needinfo? me]

The "date processed" datetime comes from Socorro, so we know for sure that's UTC. We have no idea what the other ones are or even if they're accurate.

Grabbing this to add a UTC suffix to the date processed field on the report view.

Comment 9

[Will Kahn-Greene [:willkg] ET needinfo? me]

Attachment: pr 4815: fix bug 1146956: add UTC label to date processed field

Comment 10

[Will Kahn-Greene [:willkg] ET needinfo? me]

willkg merged PR #4815: "fix bug 1146956: add UTC label to date processed field" in ebb9dc0.

Comment 11

[Will Kahn-Greene [:willkg] ET needinfo? me]

This went to prod just now in 364. Marking as FIXED.