Some Format Character dosen't work without an end char.

[noisnemid]

e.g, if the format string is written as : G y/MMM/d(E/'W'w/'Q'Q) z#hh:mm:ss B the tailed 'B' will not work. but if it's written: G y/MMM/d(E/'W'w/'Q'Q) z#hh:mm:ss B/ or G y/MMM/d(E/'W'w/'Q'Q) z#hh:mm:ss B. it will be good.

[sfsam]

Here is what I get when I paste in the first pattern with the trailing B. It looks ok?

[noisnemid]

if the formating string ends with 'B.', it'll be ok in my mac; if it ends with 'B' without '.', there will not be 'in the morning' displayed.

[noisnemid]

it works this time. i don't know what happened last time, but the 'in the morning' string really didn't show then. i'll keep testing it.

[noisnemid]

the problem got more and more interesting this time lol look!

[sfsam]

On my end, when I enable the 24-Hour Time, the B does nothing. If I disable 24-Hour Time, it says 'in the morning'. It doesn't require a trailing character after the B for it to work.

I think according to the Unicode standard, B isn't supported for 24-Hour Time, so this behavior is correct. I don't have control over how these characters are interpreted. I pass them to an Apple API that creates the time string from the format pattern. I think Apple is adhering to the standard.

From https://unicode.org/reports/tr35/tr35-dates.html: Patterns and skeletons for 24-hour-cycle time formats (using H or k) currently should not include fields with day period characters (a, b, or B); these pattern characters should be ignored if they appear in skeletons.

[noisnemid]

So Itsycal only transfers the string to an API and receive the interpreted result, this issue should not be tagged to 'BUG'.

Thank you very much for creating so practical and useful software, it helps me much!

---

PS.

At the beginning I thought this was only a tiny insignificant probelm of processing some ambiguous format string. But after reading the UNICODE LDML doc's relating sectors, and then I did some further test of the strings, I think this is a little complex but very interesting now!

Test case combinations:

Although it's meaning less to do the test if the 24-hour mode is activated according to the UNICODE LDML doc, the test cases could be recorded for refering if needed...

Uh…

Am I making simple things complex...

...

In 24-hour enabled mode, it's a little hard to predict the result by cerebrum, which is like to predict a regex's matching...less or more , they are like some undefined behaviors.

According to the doc, the result depends on the order of the patterns, too...

• MacOS's system Preferences' 24-Hour option enabled?
  • display the hour in expected way?
• zone char(z)?
  • zone char before or after the clock field(z hh:mm , or hh:mm z)?
• skeleton char?
  • a/b/B
• hour pattern is lower cased or upper cased(hh / HH)?
• trailing with a end char or not?
• other switches ...

---

[sfsam]

Ok, I will remove the bug label and close this issue. Yes, Itsycal just passes the string to the framework to interpret the pattern. That way it is done how the system would do it and I can't mess it up. :) I think it is working the way it is supposed to work, but that is a complex topic and isn't always intuitive.