I struck a similar problem a couple of times when my client's IT guy repeatedly reinstalled Windows and left Date Display in the default US format.
It wouldn't be something as simple as that causing the problem, would it?
Lord Of The Files
Think Data Pty Ltd
+61 7 5442 5624
+61 413 350 993
Comment to SysAdmins: This new system is batty. My replies are F***D UP by the system, however, I never know because I am not included in the response. This reply was empty.
When I replied I said
"I've just looked at the server and the regional settings are for Australian defaults: dd/mm/yyyy
Regardless of that setting. The behaviour should be set by the file and by the user's machine settings, shouldn't they?"
Message was edited by: Malcolm
I am sorry this site is messing you up; it can be frustrating but I believe they are working on it.
As for your date issue, be sure your file was created under same settings as your current system formats by this method (for those who may not know):
Save a copy of the file as clone (no records), then import the data into the copy (don't forget to reset serial numbers, etc.). The clone will inherit the current system formats. (quote by Comment)
But you probably already know this so I suspect it might be a reported 'text date' issue. There have been many posts about it (at least 7 that I have read), some involving // , some involving Get(CurrentDate) ... here is the only link I can find:
Basically, it says that using Get(CurrentDate) to place a date in a text field inserts a date with the file's original system settings which may be different from the current settings. (US MMDDYYYY format will persist in the field even after European date settings are selected for the file.
It has bitten people occasionally when using text dates. I am sorry that I cannot provide more links than this one right now; I shall search again later when I have a moment.
Message was edited by: LaRetta BTW, FMI responds on that link indicating that they are aware of the issue. At least two other posts in that forum were also responded to by FMI on the text date issue.
As long as the field itself is defined as a "Date" field in the table, it is storing the same numeric value no matter how it is being displayed. That's why FileMaker can extract the correct Day, Month, or Year via the calculation engine or even display it via custom layout formatting of the field.
The other responses above explain the various issues with the default date/time settings of the OS -- a whole other issue tha, the stored date data itself.
Here is a better link
This one discusses how 11.0v4 (Mac) provides a fix for Lion
http://forums.filemaker.com/posts/57c04dae9c?lang=en_US not related to this issue
Not sure if this text date bug is related to your issue but it just might be displaying the inconsistent results you see in the data viewer.
Message was edited by: LaRetta Sorry these links aren't that much help after all. I was rushing a bit. I'll find better ones for you.
It seems like I'll have to clone the file and re-import. That is boring.
It is hard for me to believe that the file was originally created with US date settings. All work has been done on Macs with Australian settings or on the server which is Windows Server 2003 with location settings set to Australia. I'll have to check with my colleague to be absolutely sure because he created the file but he is also lives and works in Australia so I can't imagine him ever having a machine with US settings.
If I'm right and the file was created with Australian settings then it is possible for a file to acquire this date bug simply by backups, copying and cloning.
The difficulty for us is that it is very hard to work around. I noticed this because I was using a date that caused an error (30th June). Any date up to the twelfth will happily switch Month for Day. The only certain system I can think of would be to decompose the date components and construct a text string from them. A custom function could do that but there is a lot of work involved in maintaining it (ie, remembering).
Another possible cause of the US Date format is that the file in its original and rudimentary state was sourced from a M/D/Y region. When first opened you would get a dialog asking if you want to keep the file's settings or use local settings. The default response for that dialog anticipated the new user would retain the original system formats. Some years ago the default response was changed to always use the local formats when opening a file that had originated with the M/D/Y formats.
Is it possible that the original developer overlooked the need to use Local Settings and this is the first time you've needed to have them diplayed in the local format?
I'm not sure that this is a credible explanation but offer it as a possible way of helping to diagnose the cause.
Yes, FileMaker always store the date in a date field as a number (integer). Not as a date, and therefore is not harmed by different date formats.
The date is calculated from the start of our calendar (nearly 2011 years ago ... whish I could write this as a calculation here to keep it correct:-)
The problem is that the our American Friends have decided to display dates in a very very peculiar way*. Instead of showing today as 2001/12/15 or 15/12/2012 they are mixing the different parts of the unit date.
The default display of a date is determined by FileMaker when entering the first value in a new file. Or when entering the first value in a new clone of a file.
So if your system is messing up your dates you should probably save a clone of each file ON A SYSTEM SET TO YOUR REGIONAL SETTINGS (windows) or WITH YOUR COUNTRY AT THE TOP IN THE INTERNATIONAL SETTINGS (mac). Then open them, enter a date, check that everything with dates calculates as you want. And then import your data (remember serial counters [killers] etc.).
*Sorry for this