Le 6 sept. 2009 à 17:02:33, Axel Luttgens a écrit :
Le 6 sept. 09 à 12:04, Yvan KOENIG a écrit :
[...]
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.
But how then should an (US) english system interpret a date string such as "6/9/2009"?
As "September 6th" or as "June 9th"?
;-)
I really don't know but at this time I don't know definitely how it behaves with 31/12/1943.
Alas, there is always a huge problem.
I receive (and I'm not the only one) files embedding dates but,
some built in France use the dd/mm/yyyy format
some built in English speaking area use the mm/dd/yyyy format
Other use the international yyyy/mm/dd format.
As AppleScript is linked to the system settings, I am force to decipher these dates using the good pl TID scheme.
Isn't it a way to get a tool allowing us to convert dates with a clean tool as we have, in spreadsheets a function allowing us to convert numbers from one base to an other one?
something like
localizeDate("12/31/1943","US")
or
localizeDate("1943/12/31","IEEE")
Yvan KOENIG (VALLAURIS, France) jeudi 3 septembre 2009 10:46:25
The problem became silly when I received luKreme's response.
I repeat: maybe he responded oddly but I'm unable to guess that x or y respond wrongly.
At this time I have:
one 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
It continue to be surprising !
Yvan KOENIG (VALLAURIS, France) dimanche 6 septembre 2009 17:23:25