|Year 2000 Issues when Upgrading from Helix Express|
Although the old Helix Express products are "Year 2000" (Y2K) compliant, data entered in versions 4.5.1 or earlier after January 1, 2000 may be stored with a date that was not intended by the user.
The point of confusion is the 'short date' format used by default by the Mac OS. This format displays dates in XX/XX/XX format (e.g: 2/16/59). By default, this format only displays two digits for the year. When dates are entered using the short date format, the user is relying on Helix to fill out the year the way they intended. When the expectations of the user and the rules of Helix do not match exactly, date entry errors can occur.
When dates are entered on a form that displays data in short date format, a significant ambiguity is involved: which century does the date refer to?
Before getting to the heart of the matter, one important distinction must be made: There is a difference between dates that are defaulted into fields and dates that are typed by the user. Default values are derived by using either the Form Time or Post Time tile. Those tiles always take their value from the Mac OS system clock (the Server's clock in the case of Client/Server) so if the Mac OS clock is correctly set, the dates will be defaulted (and therefore stored) correctly, regardless of the displayed value.
The problem is introduced when dates are typed by the user. In this case, Helix must guess at which century the user means. If the user types "5/2/19" which century is it referring to? If it is a birth date, it must be May 2, 1919, but if it is a contract renewal date, it would have to be May 2, 2019. Of course, you are allowed to name your fields any way you want, so Helix can not guess based on field names.
Helix uses very definite rules for interpreting a date when only two digits are entered for the year:
When collections are upgraded from Helix Express 4.5.1, dates that were entered incorrectly will reveal their true value. It is important to understand that this is not a bug in Helix. Helix is (and always has) correctly stored and retrieved the date data that is given to it. The problem is the assumptions that the user made when entering data with only two digits for the year.
If you upgrade from Helix Express 4.5.1 or earlier, and discover that you have dates that were entered incorrectly, there are ways to fix your data. But they require an understanding of the data, so if you are in this situation, contact our technical support department to discuss the solution that will work best for you.
(Briefly: the solutions revolve around using an abacus to add 100 years to the incorrect dates and then posting the calculated date back into the stored data.)
All other date formats (long date, e.g: February 16, 1959) show the century; displaying dates in those formats in Helix Express 4.5.1 or earlier will reveal the actual date that was entered.
Under all circumstances, typing a 4-digit year results in the 4 digits being stored, regardless of the display mode.