Display dates in a different calendar according to Regional Settings

Author: ncolmart@medinfo.fr (ncolmart)

Hi All

We are installing our application in a country where dates need to be displayed in another calendar than the standard Gregorian calendar. The application is running on Windows.

In Windows, the calendar used is defined in the Regional Settings : Control Panel / Regional and Language options
In the 'Regional Options' Tab, the format selected is 'Thai'.
With this option, the calendar used is different : the year 2011 is mapped to year 2554.
There is a difference of 543 years.

In Windows the date displayed in the bottom right corner is automatically displayed in this format.
But the system date is still in Gregorian Calendar format.
(to confirm, just open a DOS window with cmd.exe and enter 'date')

In Uniface the $date function returns the date in Gregorian format.
There is unfortunately no possibility with Uniface to display the dates in another calendar.

The main problem with this calendar, is that bissextile years are different, so the standard date controls are not valid.
Example : 29/02/2008 is valid. But corresponding 29/02/2551 is not valid !

Our need would be to store the dates in Gregorian format in the database but to display them in the local Calendar.
(preferably with any type of calendar)

Does someone already had the same need ?

Thanks for your help


  1. 2 suggestions:

    1) using format and deformat trigger to translate between the calendar systems (just adding/subtracting the number of days):

    2) embed an external calendar widget (OCX container?) which does the checks, Datepicker invocation etc.


    Author: ulrich-merkel (ulrichmerkel@web.de)
  2. What about the FORMAT/DEFORMAT-trigger?

    Set a global variable with the difference in years

    Define a globale variables

      $$TL_DATE_X   ; type date and well know display format  (if you want to do furter formating)

      $$TL_YEAR_X  ; type numeric and display format "9999"


    On format:





    On deformat (if the user enter data in format dd/mm/yyyy. Else one have to code a little bit more :) )








    Author: istiller (i2stiller@gmx.de)
  3. Dear Uli and Ingo

    I've made some tests with these triggers.
    Using Format and Deformat triggers seems to be a good solution.

    I'll make complementary testing and I'll let you know

    Thanks for your time

    Author: ncolmart (ncolmart@medinfo.fr)
  4. Just another suggestion (with uniface 9.4.):

    Look at $nlslocale and $nlsformat in Combination with date-formats, which "should" also work, because this takes the regional settings of windows.

    But never tested.


    Author: gypsilon (wva@gypsilon.de)
  5. I've tested with $NLSLOCALE set to "system"
    I've changed the regional settings to 'Thai'
    When I initialize a date with $date, the date is formatted in Thai language (even the numbers) while Windows only translate the month.

    As I can't read Thai, I've made a copy and paste of the date in google translation.
    The year displayed is 2011

    So, it seems that I cannot use $nlslocale to solve my problem.

    But many thanks for this idea.

    For information, I've made complementary tests with Format and Deformat triggers and it works well even if this solution is depending on the layout applied on the date field.
    I'll have to enhance the code in order to be sure to find the year to replace at the right place in the $format string.

    Thanks to all for your help


    Author: ncolmart (ncolmart@medinfo.fr)
  6. $nlslocale sounds like a bug in this specific situation.

    On the other hand, just use the DIS-Format for  the year with era correction (see Help-file)



    Calendar year, plus or minus number for automatic era correction.


    you can solve it without format/deformat.



    Author: gypsilon (wva@gypsilon.de)
  7. $nslocale is pretty buggy. I have three different problems with it outstanding with the Labs (and have had for several months). I'd avoid it if possible for a good while yet.

    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  8. available only with uniface 9.4, I suppose.
    Avoids year-substraction in the format/deformat trigger in an elegant manner.

    Thanks for sharing,

    Author: ulrich-merkel (ulrichmerkel@web.de)
  9. Very nice this new feature  "yyyy+nnn" resp.  DIS(dd/mm/yyy+543)

    But doesn't work in a flexible, runtime dependig manner :-(


    What about the ney syntax:   DIS ( $NLS ( NlsFormat ))   ?

    Does anyone have any experience with this new possibilities?





    Author: istiller (i2stiller@gmx.de)
  10. Yes.

    If you use the $NLS format on dates, there is no equivalent syntax entry ( ENT() ), no date validation is done on entry and odd results can happen.

    1. If your locale is EN_US, and you enter the date in EN_GB format, 23/2/10 you get 11/2/11 back (it adds 23 months to the beginning of 2010 to get the end of 2011). As a programmer, you can't trap whether this has happenned, as the date returned is viable.
    Similarly if you enter 2/23/10 in EN_GB you get 2/11/11 back.
    2. If you are in the habit of entering part of a date and letting windows fill in the rest (i.e. putting 8 in the field gets you 8/4/11), the $NLS system remembers the last date you entered (or possibly displayed) and fills the rest of the date in with those values.

    $nls_locale has other issues.
    Numeric variables are treated as floats, and therefore "Fred_%%v_counter%%" switches from returning "Fred_1" to returning "Fred_1.00"
    In fact, if you set $nls_locale=system in the idf asn, the whole thing stops working because the 'feature' above means that variable redirection doesn't work.

    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  11. I've tested DIS format including +543.
    It works well only if you want to display a date.

    But it does not work when you enter a date :
    - the date stored contains 543 more years than the date entered.
    - The date validation is made on the date stored. So bissextile year is wrongly controled.
    - the new date is displayed with 543 more years (1086 than the date entered)

    I think we will finally choose the Format/Deformat Triggers solution.
    In these triggers, we will call a Global Proc which will Format or Deformat the $format string:
    - The formatting will depends on customer deployement options. In this way, our application will continue to work worldwide.
    - The dates are always stored in Gregorian Calendar
    - The date validation is made on the Gregorian date
    - We can continue to enter only parts of the date (day, day+month, etc)

    But it will be a huge job, because we need :
    - to update the model. We must modify the Format/Deformat triggers for every date field
    - to check every form, because as soon as the database date fields are copied into variables, the display of the variables will not be updated.


    Author: ncolmart (ncolmart@medinfo.fr)
  12. Hi Nicholas,

    you can use GLOBAL UPDATES to modify the FORMAT/DEFORMAT triggers
    for the model as well as the (non-database) component fields; all depends on your search profile.
    I think it is a good start if you select all fields of datatype "date" and "combined date".

    I recommend just to add an INCLUDED PROC specified in library DATECONTROL into the triggers:

    #include DATECONTROL:<$triggerabbr>

    allows you a more flexible way of getting the job done.


    For checking the source because of copied variables, I prefer using grep, awk, perl or so against the PROC LISTINGS.

    Very fast, very easy to handle.

    Perhaps it would be a good idea to enrich these variables with a clone for the presentation
    or you create a real date_toString function (returns string) to transfer a formatted date.

    So all you need is to change:

    $just_to_show$ = "This is just a %%$my_date$%%%"

    $just_to_show$ = "This is just a %%date_toString($my_date$)%%%"

    Easy, isn't it?


    Author: ulrich-merkel (ulrichmerkel@web.de)
  13. Hi Uli

    I will investigate this solution

    Thanks for your advice


    Author: ncolmart (ncolmart@medinfo.fr)