Description of problem: The majority of the world uses dd/mm/yyyy when specifying dates, however, in the USA it is common to see mm/dd/yyyy. For dates like today, 5/4/2016 is ambiguous - is it May 4th or April 5th? Since we do not yet support localization, I suggest using the word-form month to disambiguate the date. This is a pretty low-priority issue since the duration (5 days ago) is generally a more useful way to think of the date, and it allows the user to disambiguate between the two (with some thought). More: http://joelcalifa.com/blog/unsolicited-dating-advice/ How reproducible: Run a build, create build logs, etc. This seems like a common issue with the way date strings are displayed.
We fixed this early in the 3.4 release. We removed the short format dates from the tables and changed the dates on the individual pages to be the long format.
This has been merged into ose and is in OSE v3.4.0.24 or newer.
Checked on v3.4.0.24+52fd77b 1. Start a STI build, wait for #1 build finish 2. Check build #1 started time, it's in long format: Month Date, Year 23 minutes ago – Nov 10, 2016 11:06 AM 3. Check time displaying on Builds -> Logs, it's still shown in ambiguous format Log from 11/10/16 11:06 AM to 11/10/16 11:07 AM Pods -> Logs has same ambiguous format Log from 11/10/16 11:06 AM Assigning it back
Commit pushed to master at https://github.com/openshift/origin-web-console https://github.com/openshift/origin-web-console/commit/008ff70eb949a84514970e7705a0ba3d90b150fd Bug 1333101 Use long date format on logs to remove ambiguity in month vs day Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1333101
Fixed all date references that were using the short format
This has been merged into ocp and is in OCP v3.5.0.7 or newer.
Checked against v3.5.0.7 with steps: 1. Start a STI build, wait for #1 build finish 2. Check build #1 started time at Builds -> #1 -> Details tab Started: 6 hours ago – Jan 22, 2017 8:56:16 AM 3. Check time displaying on Builds -> Logs Log from Jan 22, 2017 8:56:16 AM to Jan 22, 2017 8:56:52 AM 4. Check Pod container state at Pods -> Details tab State: Running since Jan 22, 2017 8:56:55 AM 5. Check Pods -> Logs Running: Log from Jan 22, 2017 8:56:55 AM All these are in long format: Month Date, Year Move to VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:0884