support AM/PM in date parsing/printing

[stevengj]

Support AM/PM specifier (p dateformat code, and I code for 12-hour clock) similar to strftime/strptime. Closes #23870.

Follows the quasi-standard convention of 12am=midnight (of the following day), 12pm=noon (apparently followed by all other popular libraries and languages, as discussed in #23870).

julia> Time("8:10pm", dateformat"I:MMp")
20:10:00

julia> Dates.format(ans, dateformat"II:MM p")
"08:10 PM"

[galenlynch]

12am=midnight (of the following day)

I don't understand what you mean by "of the following day". Wouldn't "2019-03-22 12:00:00 AM" be the first second of 2019-03-22?

[stevengj]

I don't understand what you mean by "of the following day". Wouldn't "2019-03-22 12:00:00 AM" be the first second of 2019-03-22?

Yes.

julia> DateTime("2019-03-22 12:00 AM", dateformat"yyyy-mm-dd II:MM p")
2019-03-22T00:00:00

By the "following" day I mean that 12am belongs to the day after midnight, not to the day before, so it is equivalent to 00:00 in a 24-hour clock for the same date (not 24:00).

[quinnj]

As far as I can tell from some googling, there are only a handful of english-speaking countries that use AM/PM, so yeah, I'm not quite sure how critical it is to support locale here. For reference (https://www.timeanddate.com/time/am-and-pm.html)

[stevengj]

Should be good to merge?

[omus]

It would have been good to use a as the specifier for AM/PM which is used in the Unicode Technical Standard #35. I'll probably open a PR for this.

[stevengj]

@omus, the p comes from the POSIX strftime, which seems more consistent with our other specifiers. e.g. we use M for minute and m for month ala POSIX, whereas UTS35 is the reverse.

[omus]

Completely reasonable. UTS35 has a standard on what using multiple specifiers in a row does which is a bit different from strftime. Following POSIX here is probably the right thing to do for now.