Product
Support
Everything Else
The ‘Show Century’ flag in Helix 7.0.2 (and International Resources)
Introduction

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

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

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-Narrow 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.)

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.)

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 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.)

itlx Resources

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.)

Additional Notes

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.