Le 6 sept. 2009 à 22:57:04, Michelle Steiner a écrit :
On Sep 6, 2009, at 8:12 AM, Yvan KOENIG wrote:
ne user (luKreme) writing that it's system set to mm/dd/yyyy is able to decipher dd/mm/yyyy
and
two user s(Michelle and Deivy) writing that it's system set to mm/dd/yyyy is unable to decipher dd/mm/yyyy
If dd is 12 or less and mm is 31 or less, it will compile, but it might not return the correct result. If the format is "mm/dd/yy" and you enter "12/07/09", you will get the wrong result if you actually meant July 12th, 2009.
It also handles overflows of dd (for 29, 30, and 32) if the month is shorter than the dd specified. For instance, if the format is mm/dd/yy, and you enter 02/31/09, the result is date "Tuesday, March 3, 2009 12:00:00 AM"
If you enter 32 or greater for dd, or 13 or greater for mm, you will get a runtime error.
You forget the context.
Le 5 sept. 2009 à 15:31:28, Doug Tallman a écrit :
For example, I get data files which have dates in the first line of text, in
a variety formats, along with some non-date information.
9/14/2009 Sports Highlights
Updates Sept. 14, 2009
So I have a handler that coerces the first line of text to a date, and it
has worked so well that it's now in dozens, if not hundreds, of scripts.
set fileDateStamp to date paragraph 1 of myText
Bob,
It appears that this works:
set fileDateStamp to date (paragraph 1 of myText)
It'll be a pain to reformat all those scripts, but a lot simpler than a lot of text processing to figure out the date format.
doug
And what would be the result if the paragraph 1 is:
31/12/1943 Arpajon (Seine et Oise)
on your machine using the mm/dd/yyyy date format ?
Yvan KOENIG (VALLAURIS, France) samedi 5 septembre 2009 17:12:20
Objet : Rép : date/Snow Leopard changed
Date : 5 septembre 2009 22:59:19 HAEC
On 5-Sep-2009, at 09:24, Yvan KOENIG wrote:
And what would be the result if the paragraph 1 is:
31/12/1943 Arpajon (Seine et Oise)
set myTest to "31/12/1943 Arpajon (Seine et Oise)" as string
set myDate to date (myTest)
return myDate
—> date "Friday, 31 December 1943 00:00:00"
Yvan KOENIG (VALLAURIS, France) samedi 5 septembre 2009 17:12:20
set myTest to "samedi 5 septembre 2009 17:12:20" as string
set myDate to date (myTest)
return myDate
—> error "Invalid date and time date samedi 5 septembre 2009 17:12:20 of «script»." number −30720
It seems clear that applying the script on a machine set to mm/dd/yyyy,
luKreme got acorrect deciphering of the date
31/12/1943.
I was not surprised by the failure with a date containing French names for day and month.
What is at least surprising is that 31/12/1943 was correctly decipher.
This is why I wrote:
I asked because on French system,
set mytest to "12/31/1943"
set myDate to date (mytest)
returns
error "Date et heure invalides date 12/31/1943 of «script»." number -30720
So, it appears that English systems are able to decipher a date using the format dd/mm/yyyy
but French system is unable to decipher a date using the format mm/dd/yyyy
In clear, non English systems are second zone ones. New kind of apartheid !
When I thought that Apple was seriously treating localization features, I was wrong.
Yvan KOENIG (VALLAURIS, France) dimanche 6 septembre 2009 12:04:11
which appeared as rude to mark J. Reed.
At this time I have no explanation of the behavior described by luKreme.
I will be glad to read a few words from him.
Yvan KOENIG (VALLAURIS, France) lundi 7 septembre 2009 10:06:29