[Main topics] [Navigation]

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.

[To top/bottom of page] 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.

[How to handle punctuation]

[To top/bottom of page] 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.

[To top/bottom of page] 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

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:

[To top/bottom of page] 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:

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.

 

[Main topics] [Navigation]
 URL:  Created: 1996-12-28  Updated:
© Docu+Design Daube, Zürich    
  Business of Docu + Design Daube Documentation issues Sharing information Klaus Daube's personal opinions Guests on this site Home of Docu + Design Daube To main page in this category To first page in series To previous page in series To next page in series To bottom of page To top of page Search this site Site map Mail to webmaster To bottom of page To top of page