Richard, Unfortunately some of the statements are not quite correct.
> • Europe: da/mo/yr, such as 01/03/2010 or 1 Mar 2010 or 1 III 2010 must read: • United Kingdom, France: dd/mm/yyyy, such as 01/03/2010 or 1 Mar 2010 • most rest of Europe: dd.mm.yyyy, such as 01.03.2010 or 1. Mar 2010 Nobody uses roman numerals nowadays except in the Chech Republic. > • ISO: yr/mo/da, such as 2010/03/01 or 2010 Mar 1 or 20100301 must read: • ISO: yyyy-mm-dd, such as 2010-03-01 or 20100301 (ISO does not use slashes) More details are found at <http://en.wikipedia.org/wiki/Date_and_time_notation_by_country> The procedure you describe to change the date format is wrong, because the locale settings are NOT applied to a file by cloning, but by OPENING the Clone for the first time. The clone as such does not contain ANY locale information until it is opened. At that time (and only then) the locale settings from the computer are set as the default for the file. Besides, defined field formats on a layout will not benefit, they remain as they are. Winfried www.fmdiff.com On 2010-02-28, at 18:48, Richard S. Russell wrote: > There are 3 components to a date: year, month, and day. There are 6 possible > orders for these 3 elements, of which 3 are in common use: > • USA: mo/da/yr, such as 03/01/2010 or Mar. 1, 2010 > • Europe: da/mo/yr, such as 01/03/2010 or 1 Mar 2010 or 1 III 2010 > • ISO: yr/mo/da, such as 2010/03/01 or 2010 Mar 1 or 20100301 > > I prefer the ISO standard and use it whenever possible. However, the client's > needs and desires trump my personal preferences, so occasionally I'm faced > with the necessity of converting dates from one format to another. > > The canonical method of doing this is to reset your computer's date > preferences, restart it to make sure they've taken effect, fire up FMP, open > up the file where the old-format dates are stored, save a clone of it (which > will automatically change the date fields to the new format), quit FMP, > change the date preferences back, restart the computer, open up the cloned > file, import the data from the old file, and thereafter work with the new > file. > > I've gone thru this complicated process often enuf that I wasn't looking > forward to having to do it again for a new client, so I decided to try > something else. I duplicated a fairly simple file that I'd created a couple > of years ago that already had the desired date formats, opened it, and > imported the old-date-format table into it. Voilá! It transferred perfectly, > and all the dates had the desired new format. Then all I had to do was > discard the tables I'd inherited in the duplication process, and I was good > to go. > > Obviously this wouldn't pay dividends if you had also invested a lot of time > building value lists, layouts, scripts, etc. in your old-date-format file. To > preserve those, you're stuck with going the clone-and-restart route. But if > all you're dealing with is a super-simple file that contains mainly data, > this shortcut might prove to be a time-saver for you. > > PS: You'll notice that I don't even acknowledge the possibility that some > idiot would still be using 2-digit years, like 03/01/10, 01/03/10, or > 10/03/01 — formats so ambiguous that your computer should be wired to give > you a mild electrical shock every time you try to use one.
