Silverstripe-framework: Nice() includes seconds

[sminnee]

Affects SS4.

In SilverStripe 4, Datetime.Nice() includes seconds. It didn't in SS3.

The underlying cause of this is that the default formatter used is IntlDateFormatter::MEDIUM, when perhaps it should be IntlDateFormatter::SHORT.

To fix, we should leave getFormatter() as-is, but have Nice() use the following formatter, which will return dates of the from Jun 1, 2018, 6:50 PM

$formatter = $this->getFormatter(IntlDateFormatter::MEDIUM, IntlDateFormatter::SHORT);

Although this isn't an API change, since we're deviating from the SS3 output (Jun 1, 2018 instead of 1/6/2018), we should do it in a minor release.

[colintucker]

IIRC, Nice() in SS3 also used 12h time with am/pm too, and a numeric month (not sure if this varies depending on locale settings?). Should we stick with the 24h time and short name month, but just lose the seconds?

[robbieaverill]

It's important also to note that this method is what we should expect developers to use commonly in the CMS when displaying dates. If they decide they don't like the change in format then they're more likely to deviate and use custom formatting which may or may not respect the current locale's formatting rules like this method does at the moment

[sminnee]

SS3's Datetime.Nice is:

01/06/2018 6:52pm

---

In SS4 this is the key line of DBDate::Nice().

$formatter = $this->getFormatter();

Produces Jun 1, 2018, 6:54:28 PM. This is the current behaviour.

$formatter = $this->getFormatter(IntlDateFormatter::MEDIUM, IntlDateFormatter::SHORT);

Produces Jun 1, 2018, 6:50 PM

$formatter = $this->getFormatter(IntlDateFormatter::SHORT, IntlDateFormatter::SHORT);

Produces 6/1/18, 6:53 PM

---

My recommendation would be to go with the last option as its closest to what we had in SS3

[chillu]

Any option that doesn't spell out the month will be ambiguous because of the crazy Americans and their month-first dates ;) And since we've removed the Member-specific date preferences in 4.x, there's no way for a user to tell which way around dates are shown (or influence that).

A "nice" date format is one that you can actually interpret unambiguously as a human, without much mental overhead.

So I'd vote for the second format, assuming that the main use case for this is CMS display, and (as Robbie mentioned) devs are welcome to spell out their preferred date formats if they're picky about this. The second format is longer, but I'm not aware of any places where we try to cram dates into small spaces (e.g. we've replaced the mini table on "page version history" with a full width one)

[sminnee]

Fair call. It's a shift from SS3 but that's fine. 👍 / 👎 to changing this in a minor release to

Jun 1, 2018, 6:50 PM

[sminnee]

OK I've looked into this and the medium format is locale dependent. In en_NZ it uses d/m/yy, but if you're in the NZ locale that should be okay. PR comgin.