Your answer match my assumptions.
You assume that :
But I disagree.
Right, but those aren't my assumptions. I was going back to Mac OS9 when it didn't matter where you were or what your settings were, but would return the same result, which I understand didn't work for you or anyone not following the US standard (make
that common practice).
But the point is that it worked consistently for any script anywhere, and you would understand that as you wrote your scripts and account for it, as would I if we had a universal date string that could be coerced.
On some machines they will create : date "Friday, September 4,
2015 at 12:00:00 AM"
but on others like mine when I use the standard format used in France, it returns :
date "Friday, September 4, 2015 at 12:00:00 AM"
I don't see a difference. But later versions, when this first started breaking, could have returned March 9, rather than Sept. 4.
If that's what you mean, I get that.
Oops, my fault. When I typed my answer the system was set to use the ISO 8601 format . With the standard format used here it returns : date "jeudi 9 avril 2015 00:00:00"
At this time, for see, the default format is set the ISO 8601 one so your first one : "9/4" issue an error.
With this setting, date "2015-09-04 10:15" funnily enough compiles flawlessly as date "vendredi 4 septembre 2015 10:15:00"
Right, that will correctly compile on some machines, but not on others, depending on your settings.
What I'm saying is that there should be a universal date format in the system that we can count on to accurately and consistently compile to or result in the correct date on any mac in any region, regardless of the local settings. That format would work
just fine for me and you both.
The only way to
always get a valid date is to ask the system to build the short date string by itself and complete it with the time components.'
Agreed, and that is exactly my complaint, that there's no consistent way to do this without doing that. Now I can easily do that in my scripts, but it's when pulling dates from outside sources in text that I have issues. AppleScript once did that flawlessly
(for me, I know) and now I have to rely on user interface.
Try to run the script below and check if what you get is what I get with my standard default format.
I'm sure that you will not.
I get a inconsistent and often inaccurate mess. I wonder if you get a different, inconsistent and inaccurate mess. (I added the maybe variable to the non-rejected string to make it easy to compare in the log)
(*01, 10:20:12, is rejected*)
(*02, 10:20 12, is rejected*)
(*03, 10:20 12, is rejected*)
(*04, 10:20-12, is rejected*)
(*05, 10:20:12 AM - Thursday, August 20, 2015 at 10:20:12 AM*)
(*06, 22:20:12 AM - Thursday, August 20, 2015 at 10:20:12 PM*)
(*07, 10:20-12 PM - Thursday, August 20, 2015 at 10:20:12 PM*)
(*08, 22:20-12 PM - Thursday, August 20, 2015 at 10:20:12 AM*)
(*09, 10:20;12, is rejected*)
(*10, 10:20,12, is rejected*)
(*11, 10:20a12, is rejected*)
(*12, 10:20/12, is rejected*)
(*13, 10:20?12, is rejected*)
(*14, 10:20@12, is rejected*)
(*15, 10@20:12, is rejected*)
(*16, 10:20, is rejected*)
(*18, 10-20, is rejected*)
(*19, 10a20, is rejected*)
(*20, 01/12/2015 - Monday, January 12, 2015 at 12:00:00 AM*)
(*21, 31-12-1943, is rejected*)
(*22, 12/31/1943 - Friday, December 31, 1943 at 12:00:00 AM*)
current date
(*101, 8/20/15 10:20:12 - Thursday, August 20, 2015 at 12:00:00 AM*)
(*102, 8/20/15 10:20 12 - Thursday, August 20, 2015 at 12:00:00 AM*)
(*103, 8/20/15 10:20 12 - Thursday, August 20, 2015 at 12:00:00 AM*)
(*104, 8/20/15 10:20-12 - Thursday, August 20, 2015 at 12:00:00 AM*)
(*105, 8/20/15 10:20:12 AM - Thursday, August 20, 2015 at 10:20:12 AM*)
(*106, 8/20/15 22:20:12 AM - Thursday, August 20, 2015 at 10:20:12 PM*)
(*107, 8/20/15 10:20-12 PM - Thursday, August 20, 2015 at 10:20:12 PM*)
(*108, 8/20/15 22:20-12 PM - Friday, August 21, 2015 at 10:20:12 AM*)
(*109, 8/20/15 10:20;12 - Thursday, August 20, 2015 at 12:00:00 AM*)
(*110, 8/20/15 10:20,12 - Thursday, August 20, 2015 at 12:00:00 AM*)
(*111, 8/20/15 10:20a12 - Thursday, August 20, 2015 at 12:00:00 AM*)
(*112, 8/20/15 10:20/12 - Thursday, August 20, 2015 at 12:00:00 AM*)
(*113, 8/20/15 10:20?12 - Thursday, August 20, 2015 at 12:00:00 AM*)
(*114, 8/20/15 10:20@12 - Thursday, August 20, 2015 at 12:00:00 AM*)
(*115, 8/20/15 10@20:12 - Thursday, August 20, 2015 at 12:00:00 AM*)
Here without any change to what I posted, I get : (*01, jeudi 20 août 2015 10:20:12*) (*02, jeudi 20 août 2015 10:20:12*) (*03, jeudi 20 août 2015 10:20:12*) (*04, jeudi 20 août 2015 10:20:12*) (*05, jeudi 20 août 2015 10:20:12*) (*06, jeudi 20 août 2015 22:20:12*) (*07, jeudi 20 août 2015 10:20:12*) would be 22 (*08, jeudi 20 août 2015 22:20:12*) (*09, jeudi 20 août 2015 10:20:00*) (*10, jeudi 20 août 2015 10:20:00*) (*11, jeudi 20 août 2015 10:20:00*) (*12, jeudi 20 août 2015 10:20:00*) (*13, jeudi 20 août 2015 10:20:00*) (*14, jeudi 20 août 2015 10:20:00*) (*15, 10@20:12, is rejected*) (*16, jeudi 20 août 2015 10:20:00*) (*17, jeudi 20 août 2015 10:20:00*) (*18, jeudi 20 août 2015 10:20:00*) (*19, 10a20, is rejected*) (*20, mardi 1 décembre 2015 00:00:00*) (*21, vendredi 31 décembre 1943 00:00:00*) (*22, 12/31/1943, is rejected*) tell current application current date (*101, jeudi 20 août 2015 10:20:12*) (*102, jeudi 20 août 2015 10:20:12*) (*103, jeudi 20 août 2015 10:20:12*) (*104, jeudi 20 août 2015 10:20:12*) (*105, jeudi 20 août 2015 10:20:12*) (*106, jeudi 20 août 2015 22:20:12*) (*107, jeudi 20 août 2015 10:20:12*) would be 22 (*108, jeudi 20 août 2015 22:20:12*) (*109, jeudi 20 août 2015 10:20: 00*) (*110, jeudi 20 août 2015 10:20: 00*) (*111, jeudi 20 août 2015 10:20: 00*) (*112, jeudi 20 août 2015 10:20: 00*) (*113, jeudi 20 août 2015 10:20: 00*) (*114, jeudi 20 août 2015 10:20: 00*) (*115, jeudi 20 août 2015 00:00:00*) end tell
So you see that on your system, several formats are rejected which are correctly treated here. How may we ask Apple to use an universal format? It's not its duty to force the entire world to use the ISO 8601 format which was designed to solve this kind of format but as you know, many US citizen are not only refusing it (as they refuse the metric system) but refusing the 24 hours format continuing to use the AM/PM one.
I tried to work on the long time with the ISO 8601 format as default but I was forced to move back to the old dd/mm/yyyy one because 95% of what I receive as a French citizen is using it or its awful cousin dd/mm/yy.
It seems clear that when we need to ask an user to enter a date time, the best way is to use something resembling more or less to Shane's proposal. Alas, it will not solve the reverse problem : how to decipher a date which we receive in ##/##/#### format. When one of the two digits number is greater than 12 or when the two digits numbers are equal it's easy. But this leave a lot of cases where the problem can't be solved.
Hurry up, all of us, vote ISO 8601 ;-)
Yvan KOENIG running Yosemite 10.10.5 in French (VALLAURIS, France) jeudi 20 août 2015 20:06:22
|