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 15:24:47 -0500
Quincey,
> On Jan 3, 2017, at 14:46, Quincey Morris <email@hidden> wrote:
>
>> On Jan 3, 2017, at 05:00 , Sandor Szatmari <email@hidden> 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 (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