can strftime() product non-locale specific (i.e. UTC) results?

[Mike Conmackie]

Greetings,

Is there any way to force strftime() to ignore locale settings when
formatting the resulting string? I have a requirement to create a specific
date-time string format in UTC. gmtime() will populate a struct tm with the
correct values but strftime() always assumes that the values are in local
time. I could manually adjust the struct tm values so that strftime() would
generate the desired string but it gets really ugly when the locale is west
of 0 degrees longitude. Furthermore, experimentation has shown that
strftime() can correctly adjust the values when they exceed the normal upper
range but not when they are negative (i.e. after an arbitrary subtraction
which would be required to adjust local time appropriately for locales west
of 0 degrees longitude). Would using putenv("TZ=UTC0 DUT") with tzset()
solve the problem (assuming that I have no need of locally adjusted time)?
Any thoughts/help would be greatly appreciated. Thanks.

Mike

[Richard Bos]

"Mike Conmackie" <mc**********@S PAMcogeco.ca> wrote:

Is there any way to force strftime() to ignore locale settings when
formatting the resulting string?

No; the definition of strftime() in the Standard demands that it uses
the current locale. However, you can try to
- use setlocale(LC_TI ME, 0) to determine the current locale, then
either;
- use setlocale(LC_TI ME, "C") to set the locale to the default "C"
locale, or
- use setlocale(LC_TI ME, "UTC") to attempt to set the time locale to
UTC (or whatever other value happens to work for you), then
- use strftime(), then
- use setlocale(LC_TI ME, saved_value) to set the locale back.

Unfortunately, you can _try_ doing this, but there's no guarantee either
that the "C" locale uses UTC, or that other locales such as "UTC" can be
set.

As for tzset(), it is IIRC a POSIX extension; in any case, it isn't ISO
C. It may work, but you'll need to ask in comp.unix.progr ammer (that is,
if it _is_ POSIX).

Richard

[Michael Wojcik]

In article <Ji************ ****@read1.cgoc able.net>, "Mike Conmackie" <mc**********@S PAMcogeco.ca> writes:

Is there any way to force strftime() to ignore locale settings when
formatting the resulting string?
Yes: don't use the conversion specifiers which are locale-sensitive.
I have a requirement to create a specific
date-time string format in UTC. gmtime() will populate a struct tm with the
correct values but strftime() always assumes that the values are in local
time.
Ah; you're talking about local time, not locale. In C, at least, the
local timezone is not part of the locale. (Whether the timezone can be
considered part of the locale at all is debatable.)

In any case, there appears to be an implementation bug or a misconfigured
environment. strftime should format the time in timeptr; it should not
convert it to local time first. That's what localtime is for. If you
pass strftime a timeptr from gmtime, UTC is what you should get.

I'd lean toward a misconfigured environment rather than a broken
implementation, but without any information about either that's just a
guess.
Would using putenv("TZ=UTC0 DUT") with tzset()
solve the problem (assuming that I have no need of locally adjusted time)?

tzset is not a standard C function.

OT: tzset is a standard POSIX / SUS function. SUSv3 notes that its
strftime behaves "as though strftime() called tzset()", which suggests
that no call to tzset would be necessary. However, SUSv3 strftime
should only use timezone information for the conversion specifiers
which display it (such as %Z). SUSv3 strftime, like the C standard
strftime (to which it defers), should not be converting the data in
the struct tm pointed to by timeptr between timezones.

Have you checked the data returned by gmtime to see that it's correct?
A misconfigured environment could produce incorrect gmtime output.

A code sample would help.

--
Michael Wojcik mi************@ microfocus.com

Do we have boyfriends? We are interested in delicious food and sweets.
And tiny animals like the cat. -- Naoko Yamano