Year 2000

---

We are receiving a lot of requests for more information about Year 2000 issues.

This was covered in a newsletter sent to all users of Athenaeum last year. However, below you will find more information.

Generally, you will NOT have a problem with the Year 2000 and Athenaeum. Because Athenaeum and Athenaeum Light are FileMaker Pro based and we have taken special care to handle date calculations with four digit years. Here is the description from FileMaker Inc of how FileMaker Pro handles dates. You can find more detailed information from their web pages, if you need it.

We are really sorry, but you WILL have a problem in the year 3000.

---

SumWare Consulting use FileMaker Inc's FileMaker Pro software to develop solutions. Our solutions use version 3.0 and 4.0 of FileMaker Pro (we do not support prior versions).

Below is an extract of FileMaker Inc's description of Year 2000 behaviour of FileMaker Pro.

Summary

FileMaker Pro handles dates through the year 3000 and handles the leap year in the year 2000.

FileMaker Pro 3.0 and newer versions address the entry of dates containing only two digits for the year by expanding the two-digit year date entries into four-digits based on the current year and the particular entry, as described below. This way the user is made immediately aware of how the date is being interpreted. In addition, FileMaker Pro 3.0 and newer versions support legacy data by continuing to interpret existing two-digit year date entries as "19xx".

Details

For existing data:

All versions of FileMaker interpret any two-digit year already present in an existing database as "19xx" (the 20th century, not merely the current century). This ensures that existing dates are interpreted consistently.

For newly entered or modified data:

FileMaker Pro 3.0 and newer versions interpret newly entered or modified two-digit years in date fields according to the following rules and expand two-digit years to four-digits if the result is other than "19xx":

If the current year is among the LAST ten years of the century (as in 1990-1999 or 2090-2099), then any two-digit year in the range 00-09 will be treated as a year in the FOLLOWING century. (For example, if it's 1998, then 03 will be expanded to 2003 but 83 will be considered 1983.)

If the current year is among the FIRST ten years of the century (as in 2000-2009), then any two-digit year in the range 90-99 will be treated as a year in the PREVIOUS century. (For example, if it's 2002, then 97 will be treated as 1997 but 83 will be considered 2083.)

The behavior is determined by what the current year is, for example:

In the year 1996:	In the year 2001:	In the year 2011:
1/1/01 -> 1/1/2001	1/1/01 -> 1/1/2001	1/1/01 -> 1/1/2001
1/1/10 -> 1/1/1910	1/1/10 -> 1/1/2010	1/1/10 -> 1/1/2010
1/1/99 -> 1/1/1999	1/1/99 -> 1/1/1999	1/1/99 -> 1/1/2099

This two-digit year expansion only occurs for dates entered into date fields via Browse mode in FileMaker Pro 3.0 and newer versions; it does not occur by entering dates via other methods.

Specifically, this behavior is not adopted if the data is imported via Import Records, entered via the web companion, modified via scripting or Apple Events, via drag-and-drop to a non-active field or for dates entered in the calculation dialog, etc. Any two-digit dates entered into FileMaker this way will be treated as "19xx", not whatever the current century is but actually "19". To avoid possible confusion, a complete four-digit year should be used.

FileMaker Pro 3.0 Server

Databases and scripts running under FileMaker Pro 3.0 Server will behave as they would under the peer-to-peer (regular) version of FileMaker Pro 3.0.

So when do you need to think about this?

Specifically, you should think about this when you are IMPORTING data into Athenaeum. Any data that you import that includes dates, such as the date of purchase of the catalogue item, will always be considered to be purchased in the century 19xx IF the imported date is of the format dd/mm/yy instead of dd/mm/yyyy. However, given that no-one has yet purchased anything in the year 2000 or greater, this is not a problem!