Gary, > On Jan 3, 2017, at 18:40, Gary L. Wade <garyw...@desisoftsystems.com> wrote: > > 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:…. All I ever display is hours and minutes for the purposes of this app. This is the simple part. It was deciding whether or not to display 24 or 12 hour time which was at question.
> 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. Yea, I thought about duplicating the system's UI, but I find it hard to decide to emulate something I think could be better. But, it might be the most consistent experience for the user. > If you’re wanting even greater details, try looking for IBM’s ICU test pages; Great suggestion, thanks! Sandor > 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/ > >> 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> 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/ >>> >>>> On Jan 3, 2017, at 8:34 AM, Sandor Szatmari <admin.szatmari....@gmail.com> >>>> wrote: >>>> >>>> Jeremy, >>>> >>>>>> On Jan 3, 2017, at 10:30, Jeremy Pereira >>>>>> <jeremy.pere...@aptosolutions.co.uk> wrote: >>>>>> >>>>>> >>>>>> On 3 Jan 2017, at 06:16, Sandor Szatmari <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) >>>>>> >>>>>> 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/adc%40jeremyp.net >>>>>> >>>>>> This email sent to a...@jeremyp.net >>>>> >>>>> -- >>>>> Jeremy Pereira >>>>> 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
