DEV Community

Peter + AI
Peter + AI

Posted on

Fixing Legacy Dates in Uniface 10: The $NLS\_DISABLE\_NON\_GREGORIAN\_CALENDAR Switch

#uniface #legacy #calendar

This article was generated with the assistance of AI.

Migrating legacy applications is rarely a smooth ride. If you are a developer maintaining a long-standing Uniface application, you might have encountered a peculiar issue when upgrading to Uniface 10.4.03 or higher: suddenly, your date logic breaks on specific client machines.

This usually happens when your application runs in an environment with a non-Gregorian locale (like de>ar-SA for Saudi Arabia or de>th-TH for Thailand). Uniface 10 introduced enhanced NLS (National Language Support) capabilities, which are great for modernization but can be catastrophic for legacy business logic that assumes every year has 365 days and starts with "20".

Here is the quick fix and the technical "why" behind the $NLS_DISABLE_NON_GREGORIAN_CALENDAR switch.

The Problem: When 2025 Becomes 1447

Prior to Uniface 10.4.03, Uniface functions like $date, $datim, and $clock were largely indifferent to the specific calendar type of the operating system's locale. They typically returned the standard Gregorian date regardless of whether the user's PC was set to use the Hijri (Islamic) or Thai Buddhist calendar.

With the update, Uniface improved its internationalization (ticket UNI-31202). Now, if a user's PC is set to an Arabic locale using the Umm al-Qura calendar, $date might return a year like 1447 instead of 2025.

Why is this bad?

Imagine a validation script in your legacy code:

variables
  date v_compDate
endvariables

; Convert the string to a Uniface date and store it in a variable
v_compDate = $date("01-01-2000")

; Check whether the conversion was successful (optional, but recommended)
if ($procerror < 0)
  message "Error: Invalid comparison date format."
else
  if ($date > v_compDate)
      call LP_PROCESS_ORDER
  else
      message "Error: System date is invalid."
  endif
endif
Enter fullscreen mode Exit fullscreen mode

If $date returns 30/06/1447 (Hijri date), this check fails because 1447 is numerically smaller than 2000. Your valid business logic suddenly treats the current date as being in the distant past.

The Solution: The Kill Switch

Rocket Software introduced a configuration switch to force the old behavior without requiring you to rewrite your entire application or force customers to change their OS settings.

How to implement it

You need to add the following line to your assignment file (.asn), typically in the [SETTINGS] section:

[SETTINGS\]
$NLS\_DISABLE\_NON\_GREGORIAN\_CALENDAR = 1
Enter fullscreen mode Exit fullscreen mode

What it does

  • Value 1: Forces Uniface to ignore the non-Gregorian calendar settings of the locale. $date will return the Gregorian date (e.g., 2025) even if the OS is using the Islamic or Thai calendar.
  • Value 0 (or undefined): Uniface respects the OS locale's calendar system (default behavior in 10.4.03+).

Should you use it?

Yes, if you need a quick stability fix for an existing application that was never designed to handle multiple calendar systems.

No, if you are building a modern, truly global application. The "correct" way forward is to write code that is calendar-aware or to explicitly format dates for internal logic while displaying them in the user's preferred format. Rocket Software marks this switch as "Strongly Discouraged" for new development because it essentially disables a feature meant to help you reach a global audience.

Have you faced similar issues migrating legacy ERP systems to modern environments? Let me know in the comments!

Top comments (0)