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

M

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=UTC0DUT") with tzset()
solve the problem (assuming that I have no need of locally adjusted time)?
Any thoughts/help would be greatly appreciated. Thanks.

Mike
 
R

Richard Bos

Mike Conmackie said:
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_TIME, 0) to determine the current locale, then
either;
- use setlocale(LC_TIME, "C") to set the locale to the default "C"
locale, or
- use setlocale(LC_TIME, "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_TIME, 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.programmer (that is,
if it _is_ POSIX).

Richard
 
M

Michael Wojcik

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=UTC0DUT") 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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,014
Latest member
BiancaFix3

Latest Threads

Top