Normalize temporal data handling across the board

[ggalmazor]

• Focus on removing all custom tailored code from WebUtils
• Review BasicElementFormatter
• Date and time format on:
  • Tables
  • Dialogs
• Solve #340

[ggalmazor]

I have a PR almost ready for this one, but I think we need to discuss about human readable temporal data format for Aggregate's web UI. Here are some options:

• [ ] Use ISO8601. It's human readable but kinda awkward
• [ ] Use localized formats (server's locale)
• [ ] Use English localized format (since the UI is not translated to any other language)

This table shows the different format styles in different locales:

Locale	Style	Date	Time
en	FULL	Friday, December 28, 2018	10:16:34 AM UTC+01:00
en	LONG	December 28, 2018	10:16:34 AM UTC+01:00
en	MEDIUM	Dec 28, 2018	10:16:34 AM
en	SHORT	12/28/18	10:16 AM
es	FULL	viernes 28 de diciembre de 2018	10H16' UTC+01:00
es	LONG	28 de diciembre de 2018	10:16:34 UTC+01:00
es	MEDIUM	28-dic-2018	10:16:34
es	SHORT	28/12/18	10:16
fr	FULL	vendredi 28 décembre 2018	10 h 16 UTC+01:00
fr	LONG	28 décembre 2018	10:16:34 UTC+01:00
fr	MEDIUM	28 déc. 2018	10:16:34
fr	SHORT	28/12/18	10:16
en	RFC1123	Fri, 4 Jan 2019 09:17:55 +0100	Fri, 4 Jan 2019 09:17:55 +0100
es	RFC1123	Fri, 4 Jan 2019 09:17:55 +0100	Fri, 4 Jan 2019 09:17:55 +0100
fr	RFC1123	Fri, 4 Jan 2019 09:17:55 +0100	Fri, 4 Jan 2019 09:17:55 +0100

(The FULL style in Spanish is broken for times) (I've added the RFC1123 format because it's the one we are currently using for date and dateTime fields)

For temporal data the system generates (like the time an export has taken to complete, for example) we would use the SHORT form, since seconds don't matter that much and, when they do, there's a log file telling you that.

[ggalmazor]

Sorry to ping you, @yanokwa, but I need some unblocking on the human-facing date and time formats to be used.

This is what is wrong:

• We display dates and dateTimes using the RFC1123 format:
  • Can't be localized (it's a format for machine-facing data interchange, not for humans)
  • It's the wrong format for dates (the RFC1123 always includes the time).
• We use a different format (ISO8601) for times

This is what I propose:

• Use the localized LONG format for user data and meta data (the FULL format feels too verbose and it's broken for some locales)
• Use the localized SHORT format for Aggregate generated data (like export times and such) (check the table above for examples)
• The initial implementation would use the system default locale (server) but it could be extended to be configurable by the user in the Site Admin > Preferences tab.

[yanokwa]

I prefer English locale on the date because the UI has not been translated. Even in the case where it has been translated, setting a server specific locale is weird cause you'll often have users from different locales on the server (e.g., US and Kenya) and so someone will be unhappy. The ideal is user-specific with the change made across the entire UI.

I'm guessing you want to use LONG and not MEDIUM for user data because you think it's important to have the time zone? If so, then agree. If not, then I'd prefer MEDIUM.

I don't love SHORT for generated data because I think it's hard for humans to parse. I particularly worry about the day/month confusion. MEDIUM is so much clearer to me.

[ggalmazor]

I'm guessing you want to use LONG and not MEDIUM for user data because you think it's important to have the time zone? If so, then agree. If not, then I'd prefer MEDIUM.

Yes :)

OK, so let's do LONG for user data and MEDIUM for generated data, all in English locale