Two important changes have been made in Helix 7.0.2 to address issues with date entry using two-digit years:

• By default, Helix 7.0.2 displays years in full 4 digit form, regardless of the display format chosen.
• The default ‘2-digit year window’ for data entry is advanced from 1920–2019 to 1950–2049.

This technote provides details on these changes, and documents methods of modifying these behaviors.

International users should note that this technote uses the US format of short date entry: MM/DD/YYYY. We leave it to you to make the DD/MM/YYYY format conversion used my many non-US systems.

Helix has always used a 100 year date range to assist in interpreting user input when a date is entered with a two-digit year. When a user enters a date, such as 3/15/59, Helix has to imply from that whether the user intended the date to be March 15, 1959,  March 15, 2059, or even March 15, 1459.

When a ‘numeric’ date format displays the year using just two digits — as is the default for the ‘with slashes’ and ‘with dashes’ formats in Helix — unexpected results can occur if the user assumes that the century that is invisibly added to the date is not what they expect. It is no longer uncommon for a user to enter a date such as ‘2/16/24’ in some cases (e.g. expiration dates) with the expectation that the year will be interpreted as 2024, while desiring (or assuming) that it will be interpreted as 1924 in others (e.g. birthdates).

For this reason, QSA ToolWorks has been recommending for years that all collections be designed to display dates with full 4-digit years. There has been a method to do this since 1997 (see below) and making this change avoids much potential confusion on the part of the entry staff, and much potential for inaccurate data entry. This is especially true in collections that deal with dates in multiple centuries.

Since its inception, Helix has used a ‘100-year window’ to interpret date entry. If a year is entered with only two digits, it is assigned the date that falls within that 100 year range. The default value for this date range has always been 1920 to 2019, so 3/15/59 was historically interpreted as March 15, 1959.

Beginning in Helix 7.0.2, the default date range is moved forward, and is now 1950 to 2049. Entering the date 10/28/24 using a 2-digit year is now interpreted as October 28, 2024 in Helix 7.0.2 and later, whereas Helix 7.0.1 and earlier interpreted this as as October 28, 1924.

This date range (aka: the ‘2-digit year window’) has been editable since Helix 4.5.2 (released in 1997) but most collection administrators have never changed the default settings. Prior to Helix 6.2 this was done by editing the HY2K resource. In Helix 6.2 and later the 2-digit year window can be moved by editing the HxShortYearRollover preference. The Helix Preference Editor provides an easy method for changing this preference.

Likewise, it has always been true that a date that is not within the 100 year date range being used as the 2-digit year window is always displayed as a full 4-digit year. If you enter the date 10/8/1492 into a date field in any version of Helix, it is displayed as a four-digit year: 10/8/1492 even though the “with slashes” and “with dashes” display formats indicate that they display the year in 2-digit form.

Final note: regardless of how a date is entered or displayed, it is always stored as an actual date, which — by definition — includes a four-digit year. Do not confuse what is displayed with what is stored in Helix.

Because of the confusion that could be caused by the change to the default date range, Helix 7.0.2 and later always display the year in full 4-digit format. Even the ‘short date’ formats — ‘with slashes’ and ‘with dashes’ — now include the century when displaying the year, regardless of whether it falls within the 100-year window, making the 2-digit year window nothing more than a convenience for data entry.

For users that require the old behavior, the new HxAlwaysShowCentury preference can be used to revert to that format. With this preference set to false the short date formats once again display the year using just 2 digits, except when the date falls outside the 100-year window as noted above. The Helix Preference Editor provides an easy method for changing this preference.

Collection designers sometimes create templates that contain rectangles precisely trimmed for the data they display. When rectangles containing dates that display 2-digit years display dates that have 4-digit years, the result may be dates that are not fully visible in the rectangle on the view.

To assist with this transition, we have developed an application (an AppleScript, actually) that examines the currently open collection to find any rectangles that are not wide enough to display the longest 4-digit year of the specified format. The application can then resize those rectangles, reduce the size of the text within, or simply report its findings. Click here to download the “Find Dates in Narrow Rectangles” application. (Design Mode access is required.)

Version 1.1, released on September 26, 2017, is enhanced to provide a warning when a widened rectangle would be wider than the rectangle it is within. (A reporting bug was also fixed.)

Apart from the possibility of data entry errors, another potential issue exists: collection designers sometimes create abaci that convert dates into text for various purposes. This has no negative side effects except when the date (as text) is linked to other data to create what is known as a concatenated key, which is often indexed for improved performance. If such an abacus contains a date field that uses one of the formats that displays the year using 2 digits, operations that compare the concatenated text will most likely not return the expected results once the date display range is modified.

This is not really a new problem — it was always an issue due to the fact that the 100-year window could be moved at any time — but now it will affect any collection that uses concatenated text containing short-format dates.

In addition, some collections use a ‘date as text’ technique that is much more difficult to detect and to deal with. In these collections, the concatenated key is posted into a text field, thereby breaking any connection to the original date from which it was derived. In this case, it does not matter whether the subsequent field is indexed or not: the text 4/5/17 is not the same as 4/5/2017 and a search on that field is going to produce unpredictable results, as data entered in Helix 7.0.2 and later will store that date as 4/5/2017, giving mixed results, including the inability to find text derived dates with two-digit years, such as those entered prior to Helix 7.0.2.

To help users detect — and address — this issue, we have done two things:

1. We have significantly enhanced the ‘Find Dates as Text in Indexes’ script for Helix 7.0.3, to the point that it is now known as Find Dates Converted To Text, and is available for download here. (Click here for a version that is compatible with Helix 7.0–7.0.2.) This new script searches all abaci, regardless of whether they are indexed or not and reports on any that include a text ◼ or styled text ◼︎ tile anywhere in their tile chain, including those found in abaci that are included in the abacus being examined. This can produce a lengthy report — including some ‘false positives’ that aren’t really problems — but the enhanced report will help you find any possible trouble spot.
2. We’ve added a new video on our YouTube channel titled Fixing Dates in Concatenated Keys. As the title implies, this video walks through the process of modifying data in a text field based on the data already in that field. Helix does not directly allow this, and this video shows one technique you can use to work within the parameters Helix establishes. Based on recent calls to technical support, we had wrongly assumed that most Helix users were familiar with this technique, so here it is, laid out in video form.

Note: BBEdit is a commercial product from Bare Bones Software, Inc. Bare Bones offers a 30-day evaluation period, during which its full feature set is available. At the end of the evaluation period, you can continue to use BBEdit for free, forever, with no nag screens or unsolicited interruptions, but with a limited set of features. (Unless you subsequently purchase the full version.)

In prior verions of Helix, the itlx resources were used to control various aspects of date and time formatting. One of the settings found in these resources is the ‘Show Century’ flag, which provided the same result as the new HxAlwaysShowCentury preference. Apple is phasing out the use of resources, and versions of macOS 10.9 and later do not handle them as fully as before. It is our recommendation that you not rely on changes to the itlx resources if you are running macOS 10.9 or later. (They have been replaced by a more robust system, but integrating it with existing Helix collections will require changes to Helix that need to be thought out carefully. We are proceeding cautiously.)

It is important to note that in the case of Helix Client/Server, it is the Server’s preference settings that determines how dates are handled. Setting these preferences on a Client workstation has no effect on Helix Client.

It is our intention to add the ‘Show Century’ property to the date display options in a future release.