Re: 12 hr vs 24 hr time display

[Alex Zavatone]

Sandor, just to let you know, all I did was go into the Date & Time System 
Preference, and do the following:
Set the Time options to
- Use a 24 hour clock
- Open ~/Library/Preferences/com.apple.menuextra.clock.plist 
- Copy and paste the contents into the email.

Set the Time options to
- Uncheck Use a 24 hour clock
- Check Show AM/PM
- Open ~/Library/Preferences/com.apple.menuextra.clock.plist 
- Copy and paste the contents into the email.

Set the Time options to
- Uncheck Use a 24 hour clock
- Uncheck Show AM/PM
- Open ~/Library/Preferences/com.apple.menuextra.clock.plist 
- Copy and paste the contents into the email.

So, all I did was give you the results that are stored within that file after I 
made those changes.  It’s up to you to do whatever you want with the data I 
sent you.  Those are the values that Apple stores.  It’s up to you to do 
anything with that data if you want to.  I just wanted to point out to you that 
it exists.

Now, I did look at the NSLocale to see it I could get something for you but 
work called.  If you still are looking for a solution in a while, I will be 
happy to see if I learn something making a category off of NSLocale to spit out 
its guts.

Happy to be of help, Sandor.  Let us know how it goes.

Cheers,
Alex Zavatone

> On Jan 4, 2017, at 2:14 PM, Sandor Szatmari  
> wrote:
> 
> Alex,
> 
> This is interesting, and thanks for digging it up.
> 
> Using this plist it appears that I could use [[NSUserDefaults 
> standardUserDefaults]  addSuiteNamed:@"com.apple.menuextra.clock"] and access 
> this data with the key 'DateFormat'.  I'm not sure I want to do this.  I 
> expect there is a degree of fragility.  Apple could change the domain or the 
> key.  But, it's good to be able to consider it.  With this I could find out 
> how the user has there clock configured.
> 
> Although, here I'm not sure I should look for 'a'.  Previously I was relying 
> on the template functionality's response to the special token of 'j'. As your 
> examples illustrate, the absence of 'a' could just indicate the preference of 
> no 'period' in the format string.  But the uppercase 'H' is a strong enough 
> indicator.
> 
> Thanks again for your time and thoughts.
> 
> Sandor
> 
> On Jan 4, 2017, at 00:54, Alex Zavatone > 
> wrote:
> 
>> OK.  All that NSLocale stuff seemed like "The right way to do it™" but…
>> 
>> Let's see if this gets you what you want.
>> 
>> Read this file:
>> 
>> ~/Library/Preferences/
>> com.apple.menuextra.clock.plist
>> 
>> And you'll see…
>> 
>> 
>> > "http://www.apple.com/DTDs/PropertyList-1.0.dtd 
>> ">
>> 
>> EEE h:mm 
>> 
>> 
>> 
>> Or
>> 
>> 
>> > "http://www.apple.com/DTDs/PropertyList-1.0.dtd 
>> ">
>> 
>> EEE h:mm a
>> 
>> 
>> Or
>> 
>> 
>> > "http://www.apple.com/DTDs/PropertyList-1.0.dtd 
>> ">
>> 
>> EEE H:mm
>> 
>> 
>> The differences here are:
>> 
>> EEE h:mm – 12 hour clock, no AM/PM shown
>> EEE h:mm a – 12 hour clock, AM/PM shown
>> EEE H:mm – 24 hour clock
>> 
>> Hope that helps.
>> 
>> - Z



smime.p7s
Description: S/MIME cryptographic signature
___

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

Re: 12 hr vs 24 hr time display

[Sandor Szatmari]

Alex,

This is interesting, and thanks for digging it up.

Using this plist it appears that I could use [[NSUserDefaults 
standardUserDefaults]  addSuiteNamed:@"com.apple.menuextra.clock"] and access 
this data with the key 'DateFormat'.  I'm not sure I want to do this.  I expect 
there is a degree of fragility.  Apple could change the domain or the key.  
But, it's good to be able to consider it.  With this I could find out how the 
user has there clock configured.

Although, here I'm not sure I should look for 'a'.  Previously I was relying on 
the template functionality's response to the special token of 'j'. As your 
examples illustrate, the absence of 'a' could just indicate the preference of 
no 'period' in the format string.  But the uppercase 'H' is a strong enough 
indicator.

Thanks again for your time and thoughts.

Sandor

> On Jan 4, 2017, at 00:54, Alex Zavatone  wrote:
> 
> OK.  All that NSLocale stuff seemed like "The right way to do it™" but…
> 
> Let's see if this gets you what you want.
> 
> Read this file:
> 
> ~/Library/Preferences/
> com.apple.menuextra.clock.plist
> 
> And you'll see…
> 
> 
>  "http://www.apple.com/DTDs/PropertyList-1.0.dtd;>
> 
> EEE h:mm 
> 
> 
> 
> Or
> 
> 
>  "http://www.apple.com/DTDs/PropertyList-1.0.dtd;>
> 
> EEE h:mm a
> 
> 
> Or
> 
> 
>  "http://www.apple.com/DTDs/PropertyList-1.0.dtd;>
> 
> EEE H:mm
> 
> 
> The differences here are:
> 
> EEE h:mm – 12 hour clock, no AM/PM shown
> EEE h:mm a – 12 hour clock, AM/PM shown
> EEE H:mm – 24 hour clock
> 
> Hope that helps.
> 
> - Z
___

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

Re: 12 hr vs 24 hr time display

[Sandor Szatmari]

Jeremy,

> On Jan 4, 2017, at 08:56, Jeremy Pereira  wrote:
> 
> 
>> On 3 Jan 2017, at 16:34, Sandor Szatmari  
>> wrote:
>> 
>> Jeremy,
>> 
>>> On Jan 3, 2017, at 10:30, Jeremy Pereira 
>>>  wrote:
>>> 
>>> 
 
>>> 
>>> 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?
> 
> Yes, because they would also be thinking that all the other apps don’t 
> respect 24 hour format including Finder windows.

Good point... 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

Re: 12 hr vs 24 hr time display

[Jeremy Pereira]

> On 3 Jan 2017, at 16:34, Sandor Szatmari  wrote:
> 
> Jeremy,
> 
>> On Jan 3, 2017, at 10:30, Jeremy Pereira 
>>  wrote:
>> 
>> 
>>> 
>> 
>> 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?

Yes, because they would also be thinking that all the other apps don’t respect 
24 hour format including Finder windows.
___

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

Re: 12 hr vs 24 hr time display

[Alex Zavatone]

OK.  All that NSLocale stuff seemed like "The right way to do it™" but…

Let's see if this gets you what you want.

Read this file:

~/Library/Preferences/
com.apple.menuextra.clock.plist

And you'll see…


http://www.apple.com/DTDs/PropertyList-1.0.dtd;>

EEE h:mm 



Or


http://www.apple.com/DTDs/PropertyList-1.0.dtd;>

EEE h:mm a


Or


http://www.apple.com/DTDs/PropertyList-1.0.dtd;>

EEE H:mm


The differences here are:

EEE h:mm – 12 hour clock, no AM/PM shown
EEE h:mm a – 12 hour clock, AM/PM shown
EEE H:mm – 24 hour clock

Hope that helps.

- Z
___

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

Re: 12 hr vs 24 hr time display

[Alex Zavatone]

On Jan 3, 2017, at 8:02 PM, Sandor Szatmari wrote:

> Alex,
> 
> On Jan 3, 2017, at 19:51, Alex Zavatone  wrote:
> 
>> 
>> On Jan 3, 2017, at 3:02 PM, Sandor Szatmari wrote:
>> 
>>> Gary,
>>> 
 On Jan 3, 2017, at 14:52, Gary L. Wade  
 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.
>> 
>> I'd expect that would be a function of the language and the locale, possibly 
>> just the locale.  Do you care what it defaults to or what it's currently set 
>> to?
> 
> That's correct and I only care so far as I can determine it as being either 
> 12 or 24.  
> 
> The relevant methods are, -dateFormatFromTemplate::: returns a format string 
> which -localizedStringFromDate:dateStyle:timeStyle: consumes to produces a 
> human readable Date string.  I am not doing the second step described here.  
> Producing he actual string the view is separate from this state stored in my 
> model.
> 
> The relevant bits are: -dateFormatFromTemplate::: with a template of 'j' 
> returns the default format string for the Locale passed as the Locale 
> argument.  I am passing [NSLocale currentLocale].  
> 
> It is my understanding that any Locale which supports the 12 hr time format 
> must represent the AM/PM as 'a' in the format string provided to 
> -localizedStringFromDate:dateStyle:timeStyle:.  So therefore the presence of 
> 'a' indicates that the Locale is configured for 12 hr time.  Otherwise, it's 
> 24 hr time.  What I am relying on is the behavior of 
> -dateFormatFromTemplate::: when passed the 'j' template.  This behavior is 
> documented here 
> http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns.
>   It specifically mentions using 'j' to determine the presence AM/PM or not.  
> i.e. 12 or 24 hr time.
> 
> Might some Locales only support 12 or 24?  Maybe, maybe not.  But if I decide 
> to only rely on the setting from Locale & Region and my interpretations are 
> good this should not matter.  The user will never see 12 or 24 for locales 
> that do not support them.
> The specific section is 
> http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Day_Period_Rules.
> 
> Thanks,
> Sandor
> 
>> 
>> - Z
>> 


Well, I am sure that some default to 12 hour time (US) and others to 24.  I 
know that you're doing this on the Mac, but last time I checked, there were 
about 900 locales supported on iOS.  The point here is that you should be able 
to get the user's current locale and see what they is set for that.

It's possible that (even though this is an issue for the Mac) that you will 
find the approach you want looking for a solution on iOS.  Check their 
currentLocale

This has relevant data and on iOS, it would be [NSLocale currentLocale];
You could look into [NSLocale 
componentsFromLocaleIdentifier:myLocaleIdentifierString] and use [[NSLocale 
currentLocale] localeIdentifier]

Also, check here.

http://stackoverflow.com/questions/35435218/ios-time-in-24-hours-format

Good luck, I think you're almost there.

Cheers.

___

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

Re: 12 hr vs 24 hr time display

[Sandor Szatmari]

Alex,

> On Jan 3, 2017, at 19:51, Alex Zavatone  wrote:
> 
> 
>> On Jan 3, 2017, at 3:02 PM, Sandor Szatmari wrote:
>> 
>> Gary,
>> 
>>> On Jan 3, 2017, at 14:52, Gary L. Wade  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.
> 
> I'd expect that would be a function of the language and the locale, possibly 
> just the locale.  Do you care what it defaults to or what it's currently set 
> to?

That's correct and I only care so far as I can determine it as being either 12 
or 24.  

The relevant methods are, -dateFormatFromTemplate::: returns a format string 
which -localizedStringFromDate:dateStyle:timeStyle: consumes to produces a 
human readable Date string.  I am not doing the second step described here.  
Producing he actual string the view is separate from this state stored in my 
model.

The relevant bits are: -dateFormatFromTemplate::: with a template of 'j' 
returns the default format string for the Locale passed as the Locale argument. 
 I am passing [NSLocale currentLocale].  

It is my understanding that any Locale which supports the 12 hr time format 
must represent the AM/PM as 'a' in the format string provided to 
-localizedStringFromDate:dateStyle:timeStyle:.  So therefore the presence of 
'a' indicates that the Locale is configured for 12 hr time.  Otherwise, it's 24 
hr time.  What I am relying on is the behavior of -dateFormatFromTemplate::: 
when passed the 'j' template.  This behavior is documented here 
http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns.
  It specifically mentions using 'j' to determine the presence AM/PM or not.  
i.e. 12 or 24 hr time.

Might some Locales only support 12 or 24?  Maybe, maybe not.  But if I decide 
to only rely on the setting from Locale & Region and my interpretations are 
good this should not matter.  The user will never see 12 or 24 for locales that 
do not support them.
The specific section is 
http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Day_Period_Rules.

Thanks,
Sandor

> 
> - Z
> 
___

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

Re: 12 hr vs 24 hr time display

[Alex Zavatone]

On Jan 3, 2017, at 3:02 PM, Sandor Szatmari wrote:

> Gary,
> 
>> On Jan 3, 2017, at 14:52, Gary L. Wade  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.

I'd expect that would be a function of the language and the locale, possibly 
just the locale.  Do you care what it defaults to or what it's currently set to?

- Z


___

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

Re: 12 hr vs 24 hr time display

[Gary L. Wade]

In that case, see if a call like this would work for you in all supported 
locales:

Objective-C
formattedDate = [NSDateFormatter localizedStringFromDate:date
dateStyle:NSDateFormatterNoStyle
timeStyle:NSDateFormatterShortStyle];

or:

Swift
let formattedDate = DateFormatter.localizedString 
(from:date,dateStyle:.none,timeStyle:.short)

If that doesn’t work, look at the comparable method in 
NSDateComponentsFormatter.
--
Gary L. Wade
http://www.garywade.com/ 
> On Jan 3, 2017, at 4:12 PM, Sandor Szatmari  
> wrote:
> 
> Gary,
> 
> On Jan 3, 2017, at 18:40, Gary L. Wade  > 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 >> > wrote:
>>> 
>>> Gary,
>>> 
>>> On Jan 3, 2017, at 14:52, Gary L. Wade >> > 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  > wrote:
> 
> Jeremy,
> 
>> On Jan 3, 2017, at 10:30, Jeremy Pereira 
>> > > wrote:
>> 
>> 
>>> On 3 Jan 2017, at 06:16, Sandor Szatmari >> > 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 

Re: 12 hr vs 24 hr time display

[Sandor Szatmari]

Gary,

> On Jan 3, 2017, at 18:40, Gary L. Wade  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  
>> wrote:
>> 
>> Gary,
>> 
>> On Jan 3, 2017, at 14:52, Gary L. Wade  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  
 wrote:
 
 Jeremy,
 
>> On Jan 3, 2017, at 10:30, Jeremy Pereira 
>>  wrote:
>> 
>> 
>> On 3 Jan 2017, at 06:16, Sandor Szatmari  
>> 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 

Re: 12 hr vs 24 hr time display

[Gary L. Wade]

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/ 
> On Jan 3, 2017, at 1:02 PM, Sandor Szatmari  
> wrote:
> 
> Gary,
> 
> On Jan 3, 2017, at 14:52, Gary L. Wade  > 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 >> > wrote:
>>> 
>>> Jeremy,
>>> 
 On Jan 3, 2017, at 10:30, Jeremy Pereira 
 > wrote:
 
 
> On 3 Jan 2017, at 06:16, Sandor Szatmari  > 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)
>  

Re: 12 hr vs 24 hr time display

[Sandor Szatmari]

Sean,

> On Jan 3, 2017, at 15:32, Sean McBride  wrote:
> 
> On Tue, 3 Jan 2017 11:26:48 -0500, Sandor Szatmari said:
> 
>> What I was asking for clarity on is the fact that there is no way to
>> detect that the user prefers 24 hr time display if they only choose
>> method 1, the Date & Time checkbox.  Should I allow my users to set 12
>> hr time but override it to 24 hr time if the Language & Region checkbox
>> is checked?  This doesn't feel right.  I feel like Apple left room for
>> ambiguity in their design here.
> 
> If I were you I would just forget about the setting for the menu bar clock.  
> I agree it's weird that it even exists (file a bug) but it's clearly meant 
> only for the menu bar clock.  Just use NSDateFormatter and add some UI in 
> your app showing the user the proper place to set her preferred date/time 
> format options.

I'm coming around to something like this.  Thanks!  

Sandor
> 
> Cheers,
> 
> -- 
> 
> Sean McBride, B. Eng s...@rogue-research.com
> Rogue Researchwww.rogue-research.com 
> Mac Software Developer  Montréal, Québec, Canada
> 
> 

___

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

Re: 12 hr vs 24 hr time display

[Sandor Szatmari]

Gary,

> On Jan 3, 2017, at 14:52, Gary L. Wade  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  
>> wrote:
>> 
>> Jeremy,
>> 
 On Jan 3, 2017, at 10:30, Jeremy Pereira 
  wrote:
 
 
 On 3 Jan 2017, at 06:16, Sandor Szatmari  
 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

Re: 12 hr vs 24 hr time display

[Sean McBride]

On Tue, 3 Jan 2017 11:26:48 -0500, Sandor Szatmari said:

>What I was asking for clarity on is the fact that there is no way to
>detect that the user prefers 24 hr time display if they only choose
>method 1, the Date & Time checkbox.  Should I allow my users to set 12
>hr time but override it to 24 hr time if the Language & Region checkbox
>is checked?  This doesn't feel right.  I feel like Apple left room for
>ambiguity in their design here.

If I were you I would just forget about the setting for the menu bar clock.  I 
agree it's weird that it even exists (file a bug) but it's clearly meant only 
for the menu bar clock.  Just use NSDateFormatter and add some UI in your app 
showing the user the proper place to set her preferred date/time format options.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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

Re: 12 hr vs 24 hr time display

[Sandor Szatmari]

Quincey,

> On Jan 3, 2017, at 14:46, Quincey Morris 
>  wrote:
> 
>> On Jan 3, 2017, at 05:00 , Sandor Szatmari  
>> 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

Re: 12 hr vs 24 hr time display

[Gary L. Wade]

Is there a problem with using +[NSDateFormatter 
localizedStringFromDate:dateStyle:timeStyle:]?  Depending on your needs, you 
might also consider +[NSCalendar autoupdatingCurrentCalendar].

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.
--
Gary L. Wade
http://www.garywade.com/ 
> On Jan 3, 2017, at 8:34 AM, Sandor Szatmari  
> wrote:
> 
> Jeremy,
> 
>> On Jan 3, 2017, at 10:30, Jeremy Pereira 
>>  wrote:
>> 
>> 
>>> On 3 Jan 2017, at 06:16, Sandor Szatmari  
>>> 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

Re: 12 hr vs 24 hr time display

[Quincey Morris]

On Jan 3, 2017, at 05:00 , Sandor Szatmari  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.

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.

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.


___

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

Re: 12 hr vs 24 hr time display

[Sandor Szatmari]

Alex,

> On Jan 3, 2017, at 13:47, Alex Zavatone  wrote:
> 
> iOS or Mac?
> 
> In any case, this will help you out to no end.
> 
> http://NSDateformatter.com/

Thanks, I'll check this out.
> 
> And note that the case of the letters you use in your formatter matter.

I don't think I said case doesn't matter.  It certainly does... e.g. A vs. a, H 
vs. h, Y vs. y, ...  have significance.  As far as I'm aware, and according to 
http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns
 there is only one specifier for AM/PM, and that is lowercase 'a', and it is 
germane only to 12 hr time format strings.  'A' specifies milliseconds in day.  
The only discussion of case was when I explained why I didn't need to, or 
rather shouldn't, consider uppercase 'AM'.  Those tokens have independent 
significance in a format string.  To clarify for future readers of this thread, 
I was not implying case doesn't matter.  Indeed, I was saying case does matter 
and looking for lowercase 'a' was appropriate.  Thanks for pointing that out.

Sandor

> 
> GL.
> - Alex Zavatone
> 
> 
>> On Jan 3, 2017, at 12:16 AM, Sandor Szatmari 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.
>> 
>> 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/zav%40mac.com
>> 
>> This email sent to z...@mac.com
> 
___

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

Re: 12 hr vs 24 hr time display

[Alex Zavatone]

iOS or Mac?

In any case, this will help you out to no end.

http://NSDateformatter.com/

And note that the case of the letters you use in your formatter matter.

GL.
- Alex Zavatone


On Jan 3, 2017, at 12:16 AM, Sandor Szatmari 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.
> 
> 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/zav%40mac.com
> 
> This email sent to z...@mac.com


___

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

Re: 12 hr vs 24 hr time display

[Sandor Szatmari]

Steve,

> On Jan 3, 2017, at 12:28, Steve Christensen  wrote:
> 
>> On Jan 3, 2017, at 8:26 AM, Sandor Szatmari  
>> wrote:
>> 
>> Steve,
>> 
>>> On Jan 3, 2017, at 10:17, Steve Christensen  wrote:
>>> 
>>> In the Date & Time preference panel, I assume that you're referring to the 
>>> option on the Clock tab. If so, those settings refer only to the menubar 
>>> clock display.
>> I just think it's weird that there are two checkboxes.  It seems odd to me 
>> that one would want a 24 hr clock in the menu bar but not anywhere else.
> 
> The menubar clock settings also have options for displaying the time with or 
> without seconds, showing AM/PM, showing the day of the week, and showing the 
> date. These options all affect the final representation in the menubar, 
> independent of the locale settings, but you're focusing on just one of these.
Yes, I agree.
> 
> I have a little bit of experience with the menubar clock in the pre-OS X 
> world so I happen to know that those particular options were present as early 
> as 1992, so people have been living with the arrangement for a long time.
> 
>>> If you notice in that same preference panel, on the Date & Time tab, there 
>>> is a message at the bottom that says, "To set date and time formats, use 
>>> the Language & Region preferences." Clicking the button takes you to that 
>>> other panel, and there you will find a checkbox that lets you select 
>>> 24-hour time.
>> Yes, this is method 2 I referred to.  If you check the Language & Region 
>> checkbox it overrides the Date & Time checkbox, enabling 24 hr time display 
>> in the menu bar clock and disabling the Date & Time checkbox.  So clearly 
>> someone at Apple sees there is at least a one direction connection between 
>> these two checkboxes.
> 
> That's merely an implementation detail related to a private system feature. 
> It's no different than if you were to put such an option in your app.
I think it was the fact that Apple made a one direction connection allowing the 
clock's preference to be overridden is what made this unclear for me.
> 
>>> The Language & Region settings are what specify the locale that is used for 
>>> formatting date and time values (among other things), which is why you see 
>>> those changes reflected in the NSDateFormatter methods.
>> Yes, this discrepancy (IMHO) is what I was asking about.  I don't see why 
>> the option for the clock display would be separated from this option.
>> 
>> What I was asking for clarity on is the fact that there is no way to detect 
>> that the user prefers 24 hr time display if they only choose method 1, the 
>> Date & Time checkbox.  Should I allow my users to set 12 hr time but 
>> override it to 24 hr time if the Language & Region checkbox is checked?  
>> This doesn't feel right.  I feel like Apple left room for ambiguity in their 
>> design here.
> 
> The locale settings, in the Language & Region preference panel, specifies the 
> user's current preferences in terms of general time formatting. The clock 
> settings specify the user's current preferences for the menubar clock. I 
> don't see the ambiguity.
I guess Apple thought that setting the Language & Region 24 hr time setting was 
strong enough for them to disallow the menu bar clock from being displayed in 
12 hr format when it, the Language & Region, preference is set.

I guess part of me felt like the the clock should either be totally in sync 
with the Language & Region setting, or totally independent.  Understanding this 
better, I will have to just pick one implementation.

Thanks for everyone's opinions.

> 
> 
 On Jan 2, 2017, at 10:16 PM, Sandor Szatmari 
  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.
 
 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 

Re: 12 hr vs 24 hr time display

[Steve Christensen]

On Jan 3, 2017, at 8:26 AM, Sandor Szatmari  
wrote:
> 
> Steve,
> 
>> On Jan 3, 2017, at 10:17, Steve Christensen  wrote:
>> 
>> In the Date & Time preference panel, I assume that you're referring to the 
>> option on the Clock tab. If so, those settings refer only to the menubar 
>> clock display.
> I just think it's weird that there are two checkboxes.  It seems odd to me 
> that one would want a 24 hr clock in the menu bar but not anywhere else.

The menubar clock settings also have options for displaying the time with or 
without seconds, showing AM/PM, showing the day of the week, and showing the 
date. These options all affect the final representation in the menubar, 
independent of the locale settings, but you're focusing on just one of these.

I have a little bit of experience with the menubar clock in the pre-OS X world 
so I happen to know that those particular options were present as early as 
1992, so people have been living with the arrangement for a long time.

>> If you notice in that same preference panel, on the Date & Time tab, there 
>> is a message at the bottom that says, "To set date and time formats, use the 
>> Language & Region preferences." Clicking the button takes you to that other 
>> panel, and there you will find a checkbox that lets you select 24-hour time.
> Yes, this is method 2 I referred to.  If you check the Language & Region 
> checkbox it overrides the Date & Time checkbox, enabling 24 hr time display 
> in the menu bar clock and disabling the Date & Time checkbox.  So clearly 
> someone at Apple sees there is at least a one direction connection between 
> these two checkboxes.

That's merely an implementation detail related to a private system feature. 
It's no different than if you were to put such an option in your app.

>> The Language & Region settings are what specify the locale that is used for 
>> formatting date and time values (among other things), which is why you see 
>> those changes reflected in the NSDateFormatter methods.
> Yes, this discrepancy (IMHO) is what I was asking about.  I don't see why the 
> option for the clock display would be separated from this option.
> 
> What I was asking for clarity on is the fact that there is no way to detect 
> that the user prefers 24 hr time display if they only choose method 1, the 
> Date & Time checkbox.  Should I allow my users to set 12 hr time but override 
> it to 24 hr time if the Language & Region checkbox is checked?  This doesn't 
> feel right.  I feel like Apple left room for ambiguity in their design here.

The locale settings, in the Language & Region preference panel, specifies the 
user's current preferences in terms of general time formatting. The clock 
settings specify the user's current preferences for the menubar clock. I don't 
see the ambiguity.


>>> On Jan 2, 2017, at 10:16 PM, Sandor Szatmari  
>>> 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.
>>> 
>>> 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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: 12 hr vs 24 hr time display

[Sandor Szatmari]

Jeremy,

> On Jan 3, 2017, at 10:30, Jeremy Pereira  
> wrote:
> 
> 
>> On 3 Jan 2017, at 06:16, Sandor Szatmari  
>> 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

Re: 12 hr vs 24 hr time display

[Sandor Szatmari]

Steve,

> On Jan 3, 2017, at 10:17, Steve Christensen  wrote:
> 
> In the Date & Time preference panel, I assume that you're referring to the 
> option on the Clock tab. If so, those settings refer only to the menubar 
> clock display.
I just think it's weird that there are two checkboxes.  It seems odd to me that 
one would want a 24 hr clock in the menu bar but not anywhere else.
> 
> If you notice in that same preference panel, on the Date & Time tab, there is 
> a message at the bottom that says, "To set date and time formats, use the 
> Language & Region preferences." Clicking the button takes you to that other 
> panel, and there you will find a checkbox that lets you select 24-hour time.
Yes, this is method 2 I referred to.  If you check the Language & Region 
checkbox it overrides the Date & Time checkbox, enabling 24 hr time display in 
the menu bar clock and disabling the Date & Time checkbox.  So clearly someone 
at Apple sees there is at least a one direction connection between these two 
checkboxes.
> 
> The Language & Region settings are what specify the locale that is used for 
> formatting date and time values (among other things), which is why you see 
> those changes reflected in the NSDateFormatter methods.
Yes, this discrepancy (IMHO) is what I was asking about.  I don't see why the 
option for the clock display would be separated from this option.

What I was asking for clarity on is the fact that there is no way to detect 
that the user prefers 24 hr time display if they only choose method 1, the Date 
& Time checkbox.  Should I allow my users to set 12 hr time but override it to 
24 hr time if the Language & Region checkbox is checked?  This doesn't feel 
right.  I feel like Apple left room for ambiguity in their design here.
> 
> 
>> On Jan 2, 2017, at 10:16 PM, Sandor Szatmari  
>> 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.
>> 
>> 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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: 12 hr vs 24 hr time display

[Steve Christensen]

In the Date & Time preference panel, I assume that you're referring to the 
option on the Clock tab. If so, those settings refer only to the menubar clock 
display.

If you notice in that same preference panel, on the Date & Time tab, there is a 
message at the bottom that says, "To set date and time formats, use the 
Language & Region preferences." Clicking the button takes you to that other 
panel, and there you will find a checkbox that lets you select 24-hour time.

The Language & Region settings are what specify the locale that is used for 
formatting date and time values (among other things), which is why you see 
those changes reflected in the NSDateFormatter methods.


> On Jan 2, 2017, at 10:16 PM, Sandor Szatmari  
> 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.
> 
> 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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: 12 hr vs 24 hr time display

[Sandor Szatmari]

Quincy,



Sandor
> On Jan 3, 2017, at 04:35, Quincey Morris 
>  wrote:
> 
>> On Jan 2, 2017, at 22:16 , Sandor Szatmari  
>> 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 (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

Re: 12 hr vs 24 hr time display

[Quincey Morris]

On Jan 2, 2017, at 22:16 , Sandor Szatmari  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. :)

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.

___

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

12 hr vs 24 hr time display

[Sandor Szatmari]

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.

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com