4.2.2.1 Time, Date, and Calendar
Description
The conventions to express time, date, and calendar data tend to vary by country and language: For example, the date
November 22, 1999 is displayed in the mm/dd/yyyy format in the U.S. as 11/22/1999, but in the U.K., it is displayed in dd/mm/yyyy format as 22/11/1999. The ISO 8601 standard describes time formats. This standard has been widely adopted in Europe.
The conventions for expressing time also differ, with varying formatting schemes using AM/PM, 24-hour clock, and
designations for Daylight Saving Time.
While many countries use the Gregorian calendar, other calendars, such as Buddhist (Thailand) or Lunar (Middle East and Asia) are in use in other parts of the world. Even conventions such as the first working day of the week can vary between countries. While most Western countries consider Monday as the first working day, in the Middle East, Sunday is considered to be the first working day. This can be important when displaying calendar appointment data.
Application software must be able to format and display the time, date, and calendar data according to local cultural
conventions. The assumptions about these formats must not be embedded in the application software.
Software that provides interfaces for formatting this data according to cultural conventions or for modifying these cultural conventions is considered a provider. Software that takes advantage of the provider functions is a consumer.
Command Line Interface
At the command line, users entering time, date, or calendar information want to use familiar formats. Commands that take
this data as parameters should take the current locale into consideration when parsing. Output data can be in an international standard
format or locale-specific format, depending on the nature of the command. For example, if a command is intended for use
in scripts or programs with the output data then fed to other programmatic functions, it makes more sense to use a single standard
format. If the command is intended for human use, it is logical for the data to be in a locale-specific format.
Character Interface
Many character interfaces break up time, date, and calendar data into their component segments. For example, there might be
three fields: one for month, day, and year. These fields are often rearranged to suit various locale needs. In the U.S., the name of the month comes first, followed by the day, a comma, and then the year. For Germany, the day comes first, followed by a period, the name of the month, and then the year.
Graphical Interface
Similar to the character interface, the graphical interface often has time, date, and calendar data broken up into
components. You can arrange these components in either of the following ways:
- Generically for international use, for example:
| Time |
UTC (GMT) |
| Hours |
02 |
| Minutes |
45 |
| Seconds |
00 |
- According to the current locale, for example:
Application Protocols
Time and date information is commonly passed in protocols. Many transactions passed through protocols require a date and
time stamp; for example, financial transactions, email messages, and status messages. In most cases, the information is passed using the coordinated universal time (UTC), sometimes referred to as Greenwich Mean Time (GMT). Local time zone information is then managed at the client level for display and input. The time is converted to UTC before using the protocol. In some situations, the protocol takes the time zone information as either part of the time format, as an offset to UTC, for example, or as a separate parameter.
Storage and Interchange
Date and time are frequently stored in association with other data. They can be stored in local format with the associated
locale and time zone for context or they can be stored in a universal format, to be converted to local format at the point of display.
Calendar information is often stored on its own, for reference by functions that need to format date and time data into local calendar
format.
Application Programming Interfaces (APIs)
In APIs, date, time, and calendar information can be managed in many different ways. For example, the API might:
- Break data up into components for separate processing, for example, the month portion of a date.
- Expect a full date-time stamp in a specific format for processing, with a separate parameter to indicate the preferred
calendar.
- Assume a format based on the current locale.
Requirements for Compliance
Providers must use functions that supply:
- Locale-specific formatting for date and time.
- Parsers for dates and times entered in locale-specific format.
- Localized display names for days of the week and months of the year in long form and in short form. For example,
Sunday, Monday, and Tuesday are long form and Sun, Mon, and Tue are short form.
- First day of the week.
- Locale-specific calendar with time arithmetic capabilities, such as values for next day, n days later and the
nth day of the year.
Optionally, the provider can supply functions that modify cultural conventions under programmatic control.
The following requirements apply to consumers:
- Make no assumptions about the display format of date and time. The consumer must use locale-specific formatters.
- Do not directly parse date and time formatted strings. The consumer must use the functions provided to parse the date and
time text data entered in locale-specific formats.
- Use the locale-specific functions provided to manipulate calendar data or to do time arithmetic.
- Do not hard code messages that contain any format information for date and time, for example: Enter date
(mm/dd/yy).
Command Line Interface
Command line interfaces must consider their audience and either make provisions for entering time, date, and calendar
information in a locale-specific format along with a possibility for locale information, or use an international or universal format.
The required format must be documented.
Character Interface
Character interfaces must allow for rearrangement of components on the screen to enable different locale formats for
displaying date and time. Local calendars must be used whenever end users need to enter dates and times.
Graphical Interface
Same as "Character Interface."
Application Protocols
Date and time should be exchanged in standard forms, leaving the formatting to the display level application. Calendar
information should be exchanged as a separate parameter, where appropriate to the protocol.
Storage and Interchange
Date and time objects must be stored and interchanged in either a standardized form, or in a local form in conjunction with
locale data.
Application Programming Interfaces
See "Requirements for Compliance."
|
|
Print-friendly Version
