12h & am/pm support about tinydate

[leeoniya]

i think leaving out a feature that's used by ~400 million people on a daily basis, due to a placeholder indecision is...how to put this lightly...insane.

hh, A and a (lowercase) would be great. yes, there's some ambiguity about whether it's pm or p.m.. (i prefer the former, as i suspect most do).

[leeoniya]

{h},{AA},{aa},{a} is what i went with.

in a 12h format, 0-padded {hh} hours are not really a thing, in my experience.

[lukeed]

Hey, looks good! 😄

Maybe this could change in the future, but I think this only warrants placement in a custom dictionary:

const tinydate = require('tinydate');

// suffix, with 24h format
tinydate('{HH}:{mm} {A}', {
  A: date => date.getHours() >= 12 ? 'PM' : 'AM'
})(); // => "14:05 PM"

// suffix, with 12h override
tinydate('{HH}:{mm} {A}', {
  A: date => date.getHours() >= 12 ? 'PM' : 'AM',
  HH: date => {
    let h = date.getHours();
    return h > 12 ? h - 12 : h;
  }
})(); // => "2:05 PM"

I'm hesitant to add tons/every datetime component since (a) most will often go unused; (b) devs prefer different placeholder names, especially coming from other languages; and (c) custom dictionaries are expendable and really easy to setup.

What do you think?

[lukeed]

Leaving this open for discussion and feedback.

As mentioned, it's very easy to add this as needed, in whatever format one desires.
Also, as shown, this cascades VERY quickly as this is actually suggesting 3 new items: 12h HH format, AM/PM, and am/pm.

Due to how internal placeholders are named/read, this would require:

• hh, enforcing two-digit hours (because that's the system)
• AA, for AM/PM
• aa, for am/pm

This is close to 100B addition, most of which will be repetitive.

For now, until there's consensus, let's stick with custom dictionary 👍

[leeoniya]

Also, as shown, this cascades VERY quickly as this is actually suggesting 3 new items

the way i see it, this lib has commited to showing common numeric representations of date and time, of which a 12hr format is clearly one. supporting 12hr means also implementing am/pm, so not really an extra feature but part of the same. cascading quickly would be month names and abbrs and weekday names and abbrs.

This is close to 100B addition, most of which will be repetitive.

in my view it's 100B that should have never been shed in the first place for the sake of size. as the saying goes, "Everything should be made as simple as possible, but not simpler." 12hr support is not some edge case, and without it tinydate crosses into the "too simple" territory.

anyways, thanks for the discussion. i guess i'll extend the dictionary as you suggest.

[leeoniya]

looking through the code, and also realizing that a 12hr format would likely require an unpadded hour makes this addition non-trivial and actually better left to a custom dict which could avoid padding.

[leeoniya]

i ended up doing my own integrated variant of tinytime that doesn't hyper-optimize for size and includes month and weekday names and abbrs, which is pretty core to a time-series plotter ;)

https://github.com/leeoniya/uPlot/blob/master/src/fmtDate.js

cc @lawrence-dol :)

[jsonUK]

Adding feedback - think this is a missing feature that would benefit this library. Lowercase {hh} and either {A} or {AA}, with lowercase equivalents also seem sensible.

[lawrence-dol]

I also think this is an obvious oversight. I concur with {hh}, {AA}, {aa}. Perhaps {A.A.} & {a.a.} if you really want "a.m.", "p.m." -- but I see that only rarely and dislike it.