Quincey, > On Jan 3, 2017, at 14:46, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > >> On Jan 3, 2017, at 05:00 , Sandor Szatmari <admin.szatmari....@gmail.com> >> wrote: >> >> 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. > > I was, but (sorry) that was because I didn’t read your code carefully enough. > >> 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. > > Why can’t be the app preference simply be “Show 24 hr time” and default to > the locale setting? Which is to say, the same thing you said but without the > semi-pejorative description. This discussion has proven very helpful. Putting it that way makes me feel like I can satisfy my feeling of ambiguity by adjusting the wording in my preference panel. I feel the wording of something like 'Show 24 hr time according to Locale & Region Setting' works. Too wordy, I know, but making the UI self explanatory/teaching is important to me. > > TBH, I think the menu bar clock has an overriding setting only for historical > reasons. However, it doesn’t seem completely unlikely that a user might want > the always-visible clock to be different from formatted times. It may be that > the locale (or bureaucratic policy) might mandate that one format is used for > dates/times generally, but a specific user might be more comfortable telling > *time of day* using the opposite convention. Yea, I vacillated here for a while. It was the unidirectionally connectedness of these features that to me implied these features were coupled and yet they weren't at the same time. Apple allows this distinction when the Locale & Region 24 hr checkbox is unchecked (Locale says 12hr/clock can be 12 or 24hr), but disables the Date & Time checkbox when the Locale & Region checkbox IS checked (Locale and clock are both 24 hr). > > Similarly and analogously, a user might have reasons for setting the Mac to > GMT generally, but still want to display local time in the menu bar. > I agree with your examples but Apple has carved out a space where they disallow a distinction. I can see why they would be forced to be in sync. I can see why they would be allowed to be independent. I cannot reason why it is implemented as it is. >
Thanks, 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
