Re: 12 hr vs 24 hr time display
Re: 12 hr vs 24 hr time display
- Subject: Re: 12 hr vs 24 hr time display
- From: Sandor Szatmari <email@hidden>
- Date: Tue, 03 Jan 2017 08:00:36 -0500
Quincy,
Sandor
> On Jan 3, 2017, at 04:35, Quincey Morris <email@hidden> wrote:
>
>> On Jan 2, 2017, at 22:16 , Sandor Szatmari <email@hidden> wrote:
>>
>> There are supported methods using: (works with method 2)
>> NSString *format = [NSDateFormatter dateFormatFromTemplate:@"j" options:0 locale:[NSLocale currentLocale]];
>> BOOL is24Hour = ([format rangeOfString:@"a"].location == NSNotFound);
>
> Well of course this won’t work in every locale, not even all the English-speaking ones, since (IIRC) it’s “AM” in some of them, but I assume you’ve breezed right past that small point. :)
Are you suggesting case sensitivity is an issue here? If so, I don't think so. The template returned from this method uses 'a' as a place holder for AM/PM. e.g. It might return the string 'h a' as it does by default for the English/US locale on my system, and a is always lower case. This is described here http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns See the 'period' field in the Date Field Symbol Table and section 8.2 for my justification.
>
> It seems to me you have two choices. One is to honor the setting for time *text* and to use the date formatter result unmodified (which means you might get more characters than just the 3 or 4 or 5 that represent the time with a possible separator). Or, if your app really is more like a clock, then I’d make the 12/24 hr format a setting within the app. As you’ve seen from the menu bar clock, there does seem to be a possible distinction between clock time format and annotation time. Since you can’t access the menu bar format (no public API at least), a one-time app setting seems reasonable.
Yea, I was considering just making it an app local preference but that strikes me as crude. Ideally speaking, at best an appropriate preference for my app could be 'Override System 24 hr time preference' or something akin.
But, I might have to settle for that...
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden