How to print an ISO 8601 date using strftime()?
Pete Forman
8601 combined date and time. It also has %F and %T which
conveneniently give the extended format date and time.
The only access to the zone designator is %z which is in basic format,
i.e. without a colon separating hh and mm.
It follows from this that to print an extended format date and time
with time zone offset one must either
a) strftime(%z) to an intermediate string, then insert a colon
b) calculate the offset yourself from tm_zone, etc.
An example of desired output is 2000-04-14T10:15:00+01:00
--
Pete Forman | Disclaimer: This posting is originated by
Western Geophysical | myself and does not represent the opinion
pete....@westgeo.com | of Baker Hughes or its divisions.
Clive D.W. Feather
<gse...@kryten.bedford.waii.com> writes
>It follows from this that to print an extended format date and time
>with time zone offset one must either
> a) strftime(%z) to an intermediate string, then insert a colon
During the C99 process I made a proposal for more comprehensive formats
in strftime; for example, to have field widths or to be able to space-
fill instead of zero-fill (or vice versa). After discussion, the
consensus view was that the purpose of strftime was to deliver the
values in a well-known text form, after which the program can edit the
string in any way it desires. So your (a) is, so to speak, the approved
approach.
--
Clive D.W. Feather | Internet Expert | Work: <cl...@demon.net>
Tel: +44 20 8371 1138 | Demon Internet | Home: <cl...@davros.org>
Fax: +44 20 8371 1037 | Thus plc | Web: <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
David R Tribble
> During the C99 process I made a proposal for more comprehensive
> formats in strftime; for example, to have field widths or to be able
> the consensus view was that the purpose of strftime was to deliver the
> values in a well-known text form, after which the program can edit the
> string in any way it desires.
I'm still irritated that there is no standard way to access fractional
second (subsecond) values. Assuming that time_t is implemented with
subsecond precision, the only recourse for the library implementor
is to provide non-standard extensions (in strftime() and struct tm).
Which is contrary to the concept of a standard library.
--
David R. Tribble, mailto:da...@tribble.com, http://david.tribble.com
Douglas A. Gwyn
> I'm still irritated that there is no standard way to access fractional
Near the end of the C9x drafting process, we backpedalled on making
"improvements" to the time-related library functions, because there
was a newly formed working group (not part of WG14) tackling these
issues, and many of us in WG14 felt that it was best to let the
experts figure out what ought to be done, then consider adopting
whatever they come up with. I haven't been following that work, so
I don't know how far they've gotten in reengineering time functions.
Clive D.W. Feather
<da...@tribble.com> writes
>I'm still irritated that there is no standard way to access fractional
>second (subsecond) values.
>Which is contrary to the concept of a standard library.
I disagree. The standard library isn't intended to do *everything*, but
to provide a standard way to do what it does do.
This may be an area that is widely enough used to be worth making a part
of the Standard, but it might not. The question is whether the benefit
outweighs the cost of making every implementation provide the feature.
David R Tribble
>> I'm still irritated that there is no standard way to access
>> fractional second (subsecond) values.
> [...]
>> Which is contrary to the concept of a standard library.
Clive D.W. Feather wrote:
> I disagree. The standard library isn't intended to do *everything*,
> but to provide a standard way to do what it does do.
>
> This may be an area that is widely enough used to be worth making a
> part of the Standard, but it might not.
But again, my point still holds: if an implementation chooses a
representation for time_t that is capable of subsecond precision,
and the vendor decides to provide access to that precision, it has
no choice but to extend the standard <time.h> library functions in
non-standard ways. The result is that the C/2005 committee will
have to sort out a mess of mutually incompatible methods from
various vendors.
> The question is whether the benefit outweighs the cost of making
> every implementation provide the feature.
The counter-argument to this is the realization that mandating a few
more format specifiers for strftime() is simply not that big of a
burden, especially in light of the plethora of new specifiers that
were added in C99. Plus there's always the argument that if an
implementation is incapable of providing subsecond precision, a
subsecond format specifier would simply result in being replaced by
zeros. How hard could that be?
A little bit harder on the implementors is requiring a new member
in struct tm for subsecond time values. But this could just as
easily be handled by also mandating the presence of a guard macro in
<time.h> indicating support for the new member, something like
_TM_HAS_SUBSEC. Old code would not have to break at all.
Douglas A. Gwyn wrote:
> Near the end of the C9x drafting process, we backpedalled on making
> "improvements" to the time-related library functions, because there
> was a newly formed working group (not part of WG14) tackling these
> issues, and many of us in WG14 felt that it was best to let the
> experts figure out what ought to be done, then consider adopting
> whatever they come up with.
Okay. But it should be remembered that there are current standards
(e.g., POSIX gettimeofday(), struct timeval) that handle subsecond
time values. These, or something close to them, could be considered
for addition to ISO C.
I should also point out that the proposed improvements to C99 that
were removed did not include any provisions for subsecond time
values. I predict the same will be true for any impending changes
from the working group (which will probably not take effect until
2005 anyway).
In conclusion, I'm still irritated by the omission, and it doesn't
look like I'll have any change of heart within the next five years.
BTW, how does one contact that working group? Is Clive in it?
Paul Eggert
>But it should be remembered that there are current standards
>(e.g., POSIX gettimeofday(), struct timeval)
Actually, POSIX does not currently specify gettimeofday, perhaps
because gettimeofday's interface is a little weird. It does however
specify clock_gettime, which is better than gettimeofday.
>I should also point out that the proposed improvements to C99 that
>were removed did not include any provisions for subsecond time
>values. I predict the same will be true for any impending changes
>from the working group
My impression is that subsecond time values will be part of that
group's output. They have been in all the proposals made to the
group so far. See:
http://www.twinsun.com/tz/timeapi.html
http://www.cl.cam.ac.uk/~mgk25/c-time/
ftp://cr.yp.to/www/libtai.html
>BTW, how does one contact that working group? Is Clive in it?
He's in charge of it. I recall that there was supposed to be a mailing
list but as far as I know it hasn't really happened yet.
Antoine Leca
>
> But again, my point still holds: if an implementation chooses a
> representation for time_t that is capable of subsecond precision,
> and the vendor decides to provide access to that precision, it has
> no choice but to extend the standard <time.h> library functions in
> non-standard ways.
This is a good description of the current state of affairs.
Since this situation is seen as unfortunate, the committee is
willingful to clarify the matter. At least, Clive and I (and
others) are willingful.
> The result is that the C/2005 committee will have to sort out
> a mess of mutually incompatible methods from various vendors.
This is exactly the point that we intent to avoid...
> > The question is whether the benefit outweighs the cost of making
> > every implementation provide the feature.
>
> The counter-argument to this is the realization that mandating a few
> more format specifiers for strftime() is simply not that big of a
> burden, especially in light of the plethora of new specifiers that
> were added in C99. Plus there's always the argument that if an
> implementation is incapable of providing subsecond precision, a
> subsecond format specifier would simply result in being replaced by
> zeros. How hard could that be?
Two problems come immediately:
- what is the unit for the subsecond field: ms? dms? 盜?
"d盜" alias 100 ns unit? ns? as? variable (i.e. configurable)?
(all the above are in use right know, IIRC)
- we need a way to 0-fill the output field, which is currently
impossible with str/wcsftime: suppose you want to produce
11:38:42.06 (current time as I wrote)...
> A little bit harder on the implementors is requiring a new member
> in struct tm for subsecond time values. But this could just as
> easily be handled by also mandating the presence of a guard macro in
> <time.h> indicating support for the new member, something like
> _TM_HAS_SUBSEC. Old code would not have to break at all.
The committee received several proposals that, for various matters,
extend struct tm. The general sentiment (in the committee) is that
doing so will break binary compatibility, so is likely to break
some code. This is the core reason for having designed struct tmx, BTW.
So I believe your suggestion is not likely to hold (my personnal
advice here, I may prove wrong).
> But it should be remembered that there are current standards
> (e.g., POSIX gettimeofday(), struct timeval) that handle subsecond
> time values. These, or something close to them, could be considered
> for addition to ISO C.
I have good news for you: POSIX is under revision, and the issue
of a new type to extend time_t with subsecond resolution (and avoid
the 2038 bug) is high in the list of their priorities.
You would understand that C0X cannot standardize on something
incompatible with POSIX, so we are holding our breath currently on
this very point.
BTW, struct timeval is not likely to be *the* solution, as I read
current advices (nothing near a consensus holds, however).
> I should also point out that the proposed improvements to C99 that
> were removed did not include any provisions for subsecond time
> values. I predict the same will be true for any impending changes
> from the working group
I predict you predicted wrong, given the above...
> (which will probably not take effect until 2005 anyway).
I know the ratification of a normative amendment is a 2-year process
as a minimum, but according to my arithmetic, 2001+2 is 2003, not 2005...
(I do not expect the proposal to be stable enough before the end
of this year, which still allows 9 months...)
Antoine