12 vs. 24 hour issue, inconsistency of en-GB

[yucca42]

(This relates to issue #41 at least in the sense that considering it, I noticed this discrepancy.)

The en-GB culture uses the H formatting code (24-hour times) for times in the definitions for codes like "t". Yet, it has no explicit setting for the calendar.AM and calendar.PM properties, which means defaulting them to the en (default) locale, which in turn effectively means using 12-hour times.

This means that there's no global way of requesting for, say, a format that consists of hours only, in the locale's hour notation. If the locale definitions were consistent, we could use

function hour(d) {
return Globalize.format(d, Globalize.culture().calendar.AM !== null ? 'h tt' : "''H" );
}

(That is, use 12-hour number followed by AM/PM designator if the locale uses 12-hour times, 24-hour number otherwise.)

[kflorence]

Date formatting seems to fail on single characters unless they represent a pattern within calendar.patterns (see #63) -- I don't seem to have a problem with en-GB 24 hr time when using multiple characters such as:

Globalize.format( new Date(), "H:m", "en-GB" );

[yucca42]

Sorry, my description was a bit unclear. There are two issues:

1. The en-GB locale is illogically defined, as the pattern definitions use HH not hh, implying that 24-hour time is normal in the locale, yet defaults AM and PM to their non-null definitions in the default locale, thereby implying 12-hour time.
   '2) Due to that inconsistency, there is no way to request for, say, a presentation of time in hours, or hours and minutes, so that the locale's setting for 12/24 hours is honored - as there is no such setting.

Quoting globalize.js:

        // AM and PM designators in one of these forms:
        // The usual view, and the upper and lower case versions
        //   [ standard, lowercase, uppercase ]
        // The culture does not use AM or PM (likely all standard date formats use 24 hour time)
        //   null
        AM: [ "AM", "am", "AM" ],
        PM: [ "PM", "pm", "PM" ],

So I would expect en-GB to have AM and PM set to null.

On the other hand, testing for AM and PM being non-null to decide whether a locale normally uses 12-hour clock is clumsy, and it might be easier to do as CLDR does: the AM and PM designators are defined for all locales, and there is a separate element (property) indicating whether 12-hour or 24-hour clock is normally used.

[kflorence]

I agree that the locale is illogically defined, it should have AM: null, PM: null in its definition, though I'm not sure that having AM and PM definitions in the locale would imply 12 hr time.

I guess when you mention there is no way to request a presentation of time in hours, you are thinking of future functionality?

[yucca42]

I meant that here is no way to request a presentation of time in hours culture-specifically, i.e. using 12-hour or 24-hour as regarded normal in a culture. Well, you could programmatically check the definition of pattern ”t” in the locale to see whether it uses ”H” or ”h”, but that would be tricky.

[kflorence]

Yeah, seems like they have it set up to check for AM/PM in order to know if it should be displayed as 12hr time or 24hr time, so it is definitely a bug that "en-GB" doesn't have null values.

[rxaviers]

I'm closing this bug since Globalize 1.x is now following CLDR.