time sub standards

[Daniel Jung]

Hi

1088553069 => Wed Jun 30 01:51:22 2004 CEST

I can do the time INT string substitution,
but I want a set of "country codes", in order
for my users to be able to pick their own
preferences. This set should include American
and European date format (`month/day' vs. `day.month'),
American and European time (AM/PM vs. 24hours).
Are there more features in major communities?

Question: Is there a predefined/official set of
time subs?

Thanks
Daniel

 

[Richard Bos]

1088553069 => Wed Jun 30 01:51:22 2004 CEST

I can do the time INT string substitution,

There is no such thing as a time INT. There's time_t, but it's not
guaranteed to be an int by any means, let alone an INT.

but I want a set of "country codes", in order
for my users to be able to pick their own
preferences. This set should include American
and European date format (`month/day' vs. `day.month'),
American and European time (AM/PM vs. 24hours).
Are there more features in major communities?

Year in front of or after month and day, two- versus four-digit year,
zeroes, spaces, or nothing in front of 2:30 and 3/4/1995, and then, of
course, there is the whole "Sun/Son/Zon/Dom/Dim/Boc" diversity, and
similar for month names.

Question: Is there a predefined/official set of time subs?

ISO should have one (a web search reveals that you should be looking at
ISO 8601), but no C implementation is required to support any of them.
However, should you have a way to find out which time zone your user
requires and which time zone your computer is in (ask the user?), you
can print the required information using strftime().
The information you get from gmtime() and localtime() _should_ be
reliable, that is, should return GMT and local time respectively, if
your computer is set to the right time zone, and in anything modern will
be; however, on MS-DOS, for example, there was no standard way of
indicating what your time zone was, and the compiler had to make
assumptions.

Richard

 

[Dave Thompson]

Year in front of or after month and day, two- versus four-digit year,
zeroes, spaces, or nothing in front of 2:30 and 3/4/1995, and then, of
course, there is the whole "Sun/Son/Zon/Dom/Dim/Boc" diversity, and
similar for month names.


ISO should have one (a web search reveals that you should be looking at
ISO 8601), but no C implementation is required to support any of them.

8601 defines only *formats*, no "subs" (algorithms).

The C standard provides conversions from time_t to and from
"broken-down" struct tm in whatever the implementation considers the
local timezone, and only to (not from) broken-down UTC (called, very
slightly inaccurately, GMT), and (several, closely related) output
formatting routines that do little to handle such variations.

POSIX adds "locales" which (attempt to) allow for "cultural" (language
and convention) variation in several areas, including date/time
formats, currency/money and number formats, and alphabet ordering
(sorting) and casing; strftime() is extended to include the date/time
format items; and strptime() is added for "unformatting" input.

While POSIX does allow the locale to be explicitly set and changed by
a program, by default it is set from environment variables which can
and should be set once and used by all programs. Unless you have a
reason to do otherwise you might consider using that method.

However, should you have a way to find out which time zone your user
requires and which time zone your computer is in (ask the user?), you
can print the required information using strftime().
The information you get from gmtime() and localtime() _should_ be
reliable, that is, should return GMT and local time respectively, if
your computer is set to the right time zone, and in anything modern will
be; however, on MS-DOS, for example, there was no standard way of
indicating what your time zone was, and the compiler had to make
assumptions.

Note that time-zone -- that is, rules for how clocks are offset from
UTC/GMT, and in particular if and when "daylight savings" or "summer"
time is used -- is separate from and in addition to cultural
variation; you can have multiple timezones in one culture or country
(viz US, RU, CN) and multiple cultures in the same timezone (viz EU).
Both can be important for a good user/human interface.

- David.Thompson1 at worldnet.att.net