What I’m getting at is how relevant is it to your app that you know if and where the time-of-day indicators exist in addition to the 24-hour setting. Answering those questions should be what determines your next steps. As mentioned, the alarm clock has a long history on the Mac whereas the Unicode underpinnings for these locale settings are "relatively recent.” If all you care about is putting out a time, try using localizedStringFromDate:…. If you absolutely have to have full control over the format string, unless the user wants a change, always use the system settings, and model your override UI after that provided in the system preferences. If you’re wanting even greater details, try looking for IBM’s ICU test pages; I’m sure they’re still around somewhere, and they allow you to run through all locales in existence, even some that Apple may not currently support. -- Gary L. Wade http://www.garywade.com/ <http://www.garywade.com/> > On Jan 3, 2017, at 1:02 PM, Sandor Szatmari <admin.szatmari....@gmail.com> > wrote: > > Gary, > > On Jan 3, 2017, at 14:52, Gary L. Wade <garyw...@desisoftsystems.com > <mailto:garyw...@desisoftsystems.com>> wrote: > >> Is there a problem with using +[NSDateFormatter >> localizedStringFromDate:dateStyle:timeStyle:]? Depending on your needs, you >> might also consider +[NSCalendar autoupdatingCurrentCalendar]. > > I am looking for detecting whether or not the system defaults to 12 or 24 hr > time. The obj-c method I'm already 'parsing', -dateFormatFromTemplate:::, > returns a template string with well defined formatting tokens that are easy > to detect. Plus they directly reflect the user's Locale & Region settings. >> >> >> A user typically “sets” their region settings when they set up their Mac, >> and the choice of 12/24 hour display defaults to what the selected region >> uses. Few people change things after that, although I am, preferring a >> four-digit year vs two-digit for the short date format. > > Great point! This is exactly why I wanted to follow a user's Locale & Date > preference. The only issue I had was that the preference's place of > definition appeared vague to me. It is tenuously tied to the Date & Time > preference for the menu bar clock. Your point is good because user's decide > this once, early on. Why should they have to specify it for every > application. Maybe providing an option to override the default behavior is > the way to go. Maybe a three state toggle or matrix. > > A. Follow Locale & Region > B. Override with 12 hr > C. Override with 24 hr > > There is some redundancy in there depending on the Locale & Region setting > but, at least to me it's self explanatory. Is that too confusing? > > Thanks, > Sandor > >> -- >> Gary L. Wade >> http://www.garywade.com/ <http://www.garywade.com/> >>> On Jan 3, 2017, at 8:34 AM, Sandor Szatmari <admin.szatmari....@gmail.com >>> <mailto:admin.szatmari....@gmail.com>> wrote: >>> >>> Jeremy, >>> >>>> On Jan 3, 2017, at 10:30, Jeremy Pereira >>>> <jeremy.pere...@aptosolutions.co.uk >>>> <mailto:jeremy.pere...@aptosolutions.co.uk>> wrote: >>>> >>>> >>>>> On 3 Jan 2017, at 06:16, Sandor Szatmari <admin.szatmari....@gmail.com >>>>> <mailto:admin.szatmari....@gmail.com>> wrote: >>>>> >>>>> I am working on a small application where the primary function is to >>>>> display the time to the user. My hope was to honor the user's preference >>>>> setting. I am either missing something or honoring the user's preference >>>>> is harder than expected. >>>>> >>>>> So, there are two places to set 24 hr time display. >>>>> >>>>> 1. Date & Time preference panel >>>>> 2. Language & Region preference panel >>>>> >>>>> The cocoa frameworks react differently depending on where you set this. >>>>> >>>>> If set by method 1, cocoa frameworks seem unaware of this setting and it >>>>> appears this is cosmetic in that it only affects the display of the clock >>>>> in the NSStatusBar. >>>>> >>>>> If set by method 2, cocoa frameworks reflect this and the Date & Time >>>>> setting is disabled noting that the setting has been overridden. >>>>> >>>>> So if a user uses method 1, potentially unaware of method 2, how should >>>>> one go about determining the user's intentions. >>>> >>>> It seems obvious to me that method 1 only refers to the clock display in >>>> the menu bar and nothing else. It’s a sub setting of >>>> “Show date and time in the menu bar”. >>>> >>>> If you honour whatever preference is set by method 2 as your code fragment >>>> below does, you’ll be fine. >>>> >>> I feel like fewer people use/find method 2, simply stopping at method 1. >>> This may be a gross assumption on my part. Under my assumption they would >>> simply think my app doesn't display 24 hr time or respect the system >>> setting. Am I being to sensitive here? >>> >>> Sandor >>>> >>>>> >>>>> There are deprecated methods using: (didn't try, it's deprecated) >>>>> NSUserDefaults with the key NSShortTimeDateFormatString >>>>> >>>>> 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); >>>>> >>>>> Can anyone provide any clarity here? >>>>> >>>>> Sandor >>>>> _______________________________________________ >>>>> >>>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com >>>>> <mailto:Cocoa-dev@lists.apple.com>) >>>>> >>>>> Please do not post admin requests or moderator comments to the list. >>>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >>>>> <http://lists.apple.com/> >>>>> >>>>> Help/Unsubscribe/Update your Subscription: >>>>> https://lists.apple.com/mailman/options/cocoa-dev/adc%40jeremyp.net >>>>> <https://lists.apple.com/mailman/options/cocoa-dev/adc%40jeremyp.net> >>>>> >>>>> This email sent to a...@jeremyp.net <mailto:a...@jeremyp.net> >>>> >>>> -- >>>> Jeremy Pereira >>>> jeremy.pere...@aptosolutions.co.uk >>>> <mailto:jeremy.pere...@aptosolutions.co.uk> >>>> 07884 265457 >>
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
