Standardize Date/Time format usage

[johnd0e]

Atm we have variety of home-brewed formatting functions, like unixTimeToString, unixTimeToDateTimeString, unixTimeToHHmm, formatInterval (and perhaps a numerous local in-place formatting routines in plugins).

It'd be great to use some standardized approach instead, e.g. Intl.DateTimeFormat.

There are still some controversies:

• [ ] Should we always prefer 24h over AM/PM format? Or let it on client to choose (via locale settings of OS).
  • [ ] locale defines some other date/time formatting options, such as month/day/year order and delimiters.
• [ ] Is local time enough, or we should let arbitrary timezone, or just UTC (may be more convenient for global events)?

Affected parts:

• Core
  • [ ] Chats
  • [ ] Region scoreboard
• Plugins
  • [ ] Scoring cycle / checkpoint times
  • [ ] Player activity tracker
  • [ ] 3rd-party plugins

Note: started in https://github.com/IITC-CE/ingress-intel-total-conversion/commit/e92dd96334bc490a759876ed6b2aed739f8f365a#commitcomment-42973205

[le-jeu]

I don't find any call of unixTimeToString except in score-cycle-times with full=true (it was used to display the capture time long ago). The remaining calls assume a format with seconds at the end(that is broken on 12h cycle)

https://github.com/IITC-CE/ingress-intel-total-conversion/blob/5d593f0221882345aee92f8d54b7eabd6bd20a1b/core/code/utils_misc.js#L186-L197

Is unixTimeToHHmm supposed to format time as HH:mm or is it supposed to respect the locale ? Is getting '9:04 pm' to avoid ? Are there places we don't want to be locale dependent ?

Also, region score uses its own format https://github.com/IITC-CE/ingress-intel-total-conversion/blob/5d593f0221882345aee92f8d54b7eabd6bd20a1b/core/code/region_scoreboard.js#L432-L452

In chat, we use a date time string with milliseconds, the millisecond part is put in a <small> tag. https://github.com/IITC-CE/ingress-intel-total-conversion/blob/5d593f0221882345aee92f8d54b7eabd6bd20a1b/core/code/chat.js#L487-L491 We can't assume with locale that the milliseconds are at index 19. Also, the fractional depends on the locale too (, or ., is there anything else ?) making millisecond low-light more complex to do, also the millisecond could not be at the end of the resulting string (pm/am)

also chat input time has its own formating, https://github.com/IITC-CE/ingress-intel-total-conversion/blob/5d593f0221882345aee92f8d54b7eabd6bd20a1b/core/code/chat.js#L761-L774

[johnd0e]

Is unixTimeToHHmm supposed to format time as HH:mm or is it supposed to respect the locale ?

I suppose that we should leave unixTimeToHHmm as is, as deprecated, and switch to use Intl.DateTimeFormat directly. Maybe unixTimeToHHmm itself should be reimplemented with Intl.DateTimeFormat, but without locale considerations.

We can't assume with locale that the milliseconds are at index 19

This part may be implemented without locale considerations (it is tooltip).

[le-jeu]

We can't assume with locale that the milliseconds are at index 19

This part may be implemented without locale considerations (it is tooltip).

on the contrary, using locale here is relevant since we show a full datetime data for the user

[McBen]

In my humble opinion:

• 24h as short term solution & localized formats as long term - with localized text
• local time. (I don't care about UTC in my regular gameplay)

that would lead to these ToDo's:

• unixTimeToString should be replaced and use the fixed custom format like the other "unixTime...." functions
• regionscoreboard:formatDayHours should use a equal format

[johnd0e]

on the contrary, using locale here is relevant since we show a full datetime data for the user

We show here full and detailed (milliseconds) datetime data, and even in North America in such cases preferred 24h format:

24- and 12-hour time systems. In countries where the 12-hour clock is dominant, some professions prefer to use the 24-hour clock. For example, in the practice of medicine, the 24-hour clock is generally used in documentation of care as it prevents any ambiguity as to when events occurred in a patient's medical history.

[le-jeu]

DateTimeFormat options allow to ask for hour24 whatever the locale.

[johnd0e]

DateTimeFormat options allow to ask for hour24 whatever the locale.

Exactly. But I meant other: we may want to ignore locale settings completely for some cases where we would like to see precise values.

[johnd0e]

If using Intl.DateTimeFormat I propose to set some conventions.

• user preferences may be set globally, e.g.

  window.locale = undefined; // can be overridden
  window.localeOptions = {
  timeZone: 'Etc/GMT+3'
  hourCycle: 'h24',
  };

• these preferences may be honored or not, depending on particular needs.

  var o = window.localeOptions || {};
  var fmt = new Intl.DateTimeFormat(window.locale {
  timeStyle: 'short', // sample
  timeZone: o.timeZone
  hour12: o.hour12,
  hourCycle: o.hourCycle,
  timeZoneName: o.timeZone && 'short',
  });

  Warning: Intl.DateTimeFormat may throw errors, so we should add some wrapper.

[johnd0e]

formatInterval is used only in getHackDetailsText. But there are other similar routines in region_scoreboard.js, player-activity-tracker, and perhaps other places.

We should either make formatInterval more generic (to be applicable in more cases), or just stop exposing it.

Related:

• https://stackoverflow.com/questions/6312993/javascript-seconds-to-time-string-with-format-hhmmss