NLA - Culture sensitive functions

Numeric Punctuation
Currency Handling
Date and Time (calendar, time and date calculations)
Additional Categories

Although some customs are bound to a natural language, some others may differ between countries, even if the same language is spoken. An application program must be able to make use of country dependent representations of numbers and other items, both on input and on output.

An appropriate hierarchy of defaults should exist, so that it is not necessary to specify these things for every application. One solution may be a general parameter file. Its structure must be specified in NLA to avoid different formats from different software sources.

Numeric Punctuation

There should be a pattern definition for editing numbers (numeric punctuation). There must be ability to specify the delimiting characters used to group numerals as well as the decimal symbol. For many end-user applications the comma has emerged as the common «inter-field separator» in input data. The data itself may contain a comma, hence customization is needed here also.

Also programming languages should make use of these definitions for output formats and other presentations.

It must be noted here that in some countries, like Switzerland, there are several valid patterns for numeric punctuation. Hence there must be choices of edit patterns (predefined in the environment) as well as the capability for the user to specify them as needed. A model for these specifications can be found in setlocale.

Currency Handling

Currency symbols and monetary values must be treated with great care in code translations. Any code translation must retain the mnemonic meaning of these symbols: For example a $-sign must not be translated in any circumstances to a £-sign.

It must be noted here that in some countries, like Switzerland, there are several valid patterns for monetary punctuation. Hence there must be choices of edit patterns (predefined in the environment) as well as the capability for the user to specify them as needed. A model for these specifications can be found in setlocale.

Date and Time

Applications should be able to make use of various forms of date and time representations. An operating system must identify the form provided to the user. Applications like compilers should not use ambiguous representations like 12/10/89 where month and day cannot be distinguished. Within only ten years from the writing of this paper the ambiguity of this date format becomes even worse: What is 01/02/03?

A default presentation may be the BIH (Bureau international de l'heure with its Observatoire de Paris) standard for numeric date (yyyy-mm-dd for year-month-day) and time.

Date and time constitute an inseparable entity.

The presentation of date and time should depend on the country and language setting. Presentation of time must include the specification of the time zone. 11:03:34 has no defined meaning in a communication environment spanning half the globe. Examples are:

10. Dezember 1989, 13.17 Uhr (UT)	Swiss German
1989-12-10 T13:17:00 Z(UT)	ISO 8601

System time stamps (e.g. for accounting) must also contain this additional information. The (national) habit of «daylight saving time» otherwise destroys the continuity of time (if either subtrahend or minuend in the calculation is before/after the switching period, the calculation needs adjustment).

Calendar

The type of calendar depends on the country, sometimes on personal habits of the end-user. For example, the Arabs, Christians, Japanese and Jewish people have different conventions for numbering the years and months. Since an application may need to accept input of dates in various forms, functions for conversion of dates are needed.

In addition to the «general» calendar a «working calendar» is desired by many applications. This should be supported by the NLA to avoid multiple copies of this function in an installation. However, the user or application must be able to specify which table to be used.

Function to represent Date and Time

A function is needed, which returns a string of the desired pattern with the elements

• Type of Calendar
• Date
• Time
• Time zone or offset to Universal Time

A model for this may be DISPLAYDATE (date-time, pattern, output-string )

In the definition of pattern certain characters and special symbols represent the editing pattern. An example might be YYYY-MM-DD HH:MM:SS ZZZ to get 1989-03-28 14:10:23 CET.

Time and Date Calculation Functions

Standard functions for comparison of dates and time as well as subtracting and adding dates (and time) are required. Since the forecast of some event may only be in relation to working days, some means of specifying a «working day calendar» (as part of the country culture) must be available.

Functions needed in this area are:

• Sum and difference of dates (including or not including time). These functions depend on parameters like
  • working calendar
  • switching of time (standard time versus daylight savings time)
  • incidence of national holidays
• Transformation of time units (days, hours, weeks, working units). The ISO numbering scheme for day-number or week-number must be used.

Additional Categories

The NLA must stay open for additional requirements in this area. In the near future cultural variations of the following categories may be needed:

• Icon symbols and usage
• Measurement system
• Paper sizes

Currency is a frequent field in data bases. The associated conversion rate is additional information with frequent changes. The same concept applies to units of measure. Converting the values from one unit to another is the task of an «application» and out of the scope of the NLA.

Data base designs must provide for «units of measure» (which include currency, weight, volume). NLA provides tagging of data, but it is the responsibility of an application to use the given information, for example for conversions in presentation.