Datetime format should be self-evident, not lossy

NEW
Unassigned

Status

4 years ago
4 years ago

People

(Reporter: anaran, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
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

4 years ago
I do not agree to useing non-human-readacble dates (and yes, that's what I consider the requested variant)
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 :)
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.
Flags: needinfo?(adrian.aichner)
(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

4 years ago
(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.
(Reporter)

Comment 6

4 years ago
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.
Flags: needinfo?(adrian.aichner)
(Reporter)

Comment 7

4 years ago
(In reply to Robert Kaiser (:kairo@mozilla.com) 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.
(Reporter)

Updated

4 years ago
Summary: Datetime format should be self-evident, not lossy: use JSON → Datetime format should be self-evident, not lossy
You need to log in before you can comment on or make changes to this bug.