|The ‘Show Century’ flag in Helix 7.0.2 (and International Resources)|
Two important changes have been made in Helix 7.0.2 to address issues with date entry using two-digit years:
This technote provides details on these changes, and documents methods of modifying these behaviors.
|The Problem With 2-Digit Years||
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).
|The 2-Digit Window||
Since its inception, Helix has used a ‘100-year window’ — if a 2-digit year is entered, 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 would be interpreted as March 15, 1959.
This date range has been editable since Helix 4.5.2 (released in 1997) — by editing the HY2K resource in versions prior to Helix 7.0, or the HxShortYearRollover preference in Helix 6.2 and later — but most collection administrators have never changed the default settings.
In Helix 7.0.2, the default date range is moved forward, and is now 1950 to 2049, so that entering the date ‘10/28/24’ (‘28/10/24’ for most International users) using a 2-digit year is interpreted as October 28, 1924 (as opposed to e.g. 1824 or 2024) in Helix 7.0.1 and earlier, and as October 28, 2024 in Helix 7.0.2 and later.
It is important to note that a stored date that is not within the 100 year date range Helix has assigned to 2-digit years is displayed with its full 4-digit year. This has always been the case, and is why you can see a date displayed as 3/15/2032 in Helix, even though the ‘with slashes’ display format typically only displays a 2-digit year.
As before, the 2-digit window can be moved by editing the HxShortYearRollover preference in Helix 6 and later. The Helix Preference Editor provides an easy method for changing this setting.
|The ‘Always Show Century’ Setting||
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 window nothing more than a convenience for data entry.
For users that prefer the old behavior, the new HxAlwaysShowCentury preference can be used to revert to the old behavior. 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 has also been updated to provide an easy method for changing this setting.
|The ‘Too-Short Rectangle’ Problem||
Collection designers sometimes create templates that contain rectangles precisely trimmed for the data they display. When rectangles containing dates that display 2-digit years start displaying 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.)
|The ‘Date As Text’ Problem||
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 then 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 almost certainly affect some collections.
To assist with this transition, we have developed an application (an AppleScript, actually) that examines the currently open collection to find any indexes that should be rebuilt due to this change. Only indexes that contain an abacus that has a date whose display format is “with slashes” or “with dashes” that is subsequently converted to text are reported, since all other options already explicitly display a 4-digit year. The user can then choose to automatically rebuild these indexes, or to retrieve a report of which indexes are affected. Click here to download the updated* “Find Dates as Text in Indexes” application. (Design Mode access is required.)
v1.0.1, released May 11, 2017, fixes a bug that caused it to skip some indexes that should be rebuilt.
|The ‘Date To Text’ Problem||
Update: Since the release of this technote, it has been discovered that 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 data. Helix 7.0.2 and later will also convert dates in searches into 4-digit years, which will not be able to find text such as 4/5/17 that was entered prior to Helix 7.0.2.
To help users detect — and address — this issue, we have done two things:
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.