Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Normalize date formats across the WebUI

Description

It is becoming ver common that the OpenNMS server, the monitored devices and the UI clients are spread out across the globe, meaning that they have different timezones.

Recently, I was doing a consulting for a customer in South Africa, and noticed that the node page was showing events in the future. The thing is, I though it was the future because the timezone is not displayed on the UI, and the times you see on the UI are based on the OpenNMS server time using its own timezone (SAST), which in this case were different than my timezone (EST).

Also, by convention "5/3/2018" is ambiguous. In the US, people read this date as "May 3rd 2018", but in South America and Europe, that can be read as "5th of March 2018".

This short format is used on the node page (and dependent pages), but the rest of the UI uses a full format without timezone, for example "May 4, 2018 2:01:14 PM".

Interestingly, the date shown at the top right corner, which is the server times shows the timezone. Also, when you are looking at the graphs (at least for latest version of Meridian and Horizon), you can also see the timezone, as having this concept in mind is crucial to understand graphs.

I would imagine that when sending notifications, and the eventtime place holder is used, it doesn't contain the timezone; and maybe the reports based on JasperReports might suffer the same thing.

I propose:

1) Use a full format everywhere, similar to the current implementation but including the timezone, for example "May 4, 2018 2:01:14 PM EST".

2) Use a "sortable" format like "2018-05-04 14:01:14 EST", which is common on databases, and in fact this is how PostgreSQL displays the dates.

Acceptance / Success Criteria

None

Attachments

1
100% Done
Loading...

Lucidchart Diagrams

Activity

Alejandro Galue June 25, 2018 at 11:45 AM

Looks good to me (your assumptions and the content of the PR so far).

I'm doing a consulting this week, but I'll try this before the end of the week.

Patrick Schweizer June 23, 2018 at 10:27 PM

@agalue, @j-white: could you check if the implementation goes in the right direction? When ok I would roll it out.

Thanks!

Patrick Schweizer June 23, 2018 at 10:26 PM

I made a proof of concept and it seems to work:

https://github.com/OpenNMS/opennms/pull/2028

A couple of remarks:
1. Default pattern
I decided to use the ISO_8601 Date Time format as default since

  • it's a world wide standard,

  • is is sort able as requested and

  • it contains all information to define the time inclusive the time zone

2.Time Zone

The servers time zone is used.

3.Customize pattern

The formatting is based on java.time.format.DateTimeFormatter. The time pattern can be overridden with the opennms property org.opennms.ui.datettimeformat. So far I have only defined this property, I would suggest we use that and if we run into space problems we can then also define a property for a short format.

4. Support for java.time

The tag supports the new (as in Java 8) time classes from the package java.time but is also backwards compatible to java.util.Date

 

Alejandro Galue June 22, 2018 at 12:02 PM

Sounds good to me, thanks!

Patrick Schweizer June 22, 2018 at 12:29 AM

Here is my suggestion:

I write a custom tag that we use everywhere where we use today the <fmt:formatDate tag. Hereby we centralized the formatting of the dates / time and gained the ability to set the formatting as we want. In this tag I will use then the format supplied in opennms.properties (or a default).

@agalue, @j-white is this what we want?

Fixed

Details

Assignee

Reporter

Labels

Components

Sprint

Fix versions

Affects versions

Priority

PagerDuty

Created May 4, 2018 at 7:46 PM
Updated August 22, 2018 at 2:04 PM
Resolved August 22, 2018 at 2:04 PM