Various ways to get month name from inbuilt C library
Debanjan
to an integer value from inbuilt C/C++ library, I am familiar to
strftime. Any other means to do the same ?
santosh
ctime() and the deprecated asctime() return string representations of
their calender time and broken down time respectively. It's possible
to extract the month name (or it's abbreviation) from the string. But
strftime() is far better for this purpose.
santosh
Correction: asctime() isn't deprecated. It's just fragile to use.
Richard Bos
Also, since ctime(t) is exactly equivalent to asctime(localtime(t)), it
is equally as inadvisable.
Not that I'd say asctime() is particularly fragile. It breaks only when
its parameter is later than the year 9999 or before -999, which in
itself is good enough for daily use, although of course it is less than
perfect for general purposes. But the format it returns is particularly
useless, so strftime() is still the better choice.
Richard
Keith Thompson
> santosh <santo...@gmail.com> wrote:
[...]
>> Correction: asctime() isn't deprecated. It's just fragile to use.
>
> Also, since ctime(t) is exactly equivalent to asctime(localtime(t)), it
> is equally as inadvisable.
No, ctime() isn't quite as bad; asctime() by itself provides more
opportunities for undefined behavior.
ctime()'s argument is a pointer to a time_t. On many systems, time_t
can't even represent times outside the range that asctime() supports.
Even on systems with a wider time_t, ctime() can't call asctime()
with, for example, tm_sec==9999.
> Not that I'd say asctime() is particularly fragile. It breaks only when
> its parameter is later than the year 9999 or before -999, which in
> itself is good enough for daily use, although of course it is less than
> perfect for general purposes. But the format it returns is particularly
> useless, so strftime() is still the better choice.
Agreed. Personally, my biggest problem with asctime() isn't its
misbehavior on bad arguments (that's solvable by being careful with
what you pass it), it's the silly outdated output format, especially
the trailing '\n'. If I want to print a date, I almost always use
YYYY-MM-DD; asctime() and ctime() don't support that, but strftime()
does.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Richard Bos
> ral...@xs4all.nl (Richard Bos) writes:
> > santosh <santo...@gmail.com> wrote:
> [...]
> >> Correction: asctime() isn't deprecated. It's just fragile to use.
> >
> > Also, since ctime(t) is exactly equivalent to asctime(localtime(t)), it
> > is equally as inadvisable.
>
> No, ctime() isn't quite as bad; asctime() by itself provides more
> opportunities for undefined behavior.
>
> ctime()'s argument is a pointer to a time_t. On many systems, time_t
> can't even represent times outside the range that asctime() supports.
> Even on systems with a wider time_t, ctime() can't call asctime()
> with, for example, tm_sec==9999.
You are, of course, correct. However, I would consider that to fall
under "prone to intentional abuse" rather than "prone to accidental
misuse". So, perhaps I should say, _to the honest programmer_ ctime() is
nearly as inadvisable as asctime().
> > Not that I'd say asctime() is particularly fragile. It breaks only when
> > its parameter is later than the year 9999 or before -999, which in
> > itself is good enough for daily use, although of course it is less than
> > perfect for general purposes. But the format it returns is particularly
> > useless, so strftime() is still the better choice.
>
> Agreed. Personally, my biggest problem with asctime() isn't its
> misbehavior on bad arguments (that's solvable by being careful with
> what you pass it), it's the silly outdated output format, especially
> the trailing '\n'.
I don't know that it is outdated; I think that it never was a reasonable
format to use in the first place.
Richard
Nick Keighley
> I don't know that [asctime()] is outdated; I think that it never was a reasonable
> format to use in the first place.
isn't it reasonably common format in the US? Though mixing the time up
in the middle of the date does seem weird!
Sun Sep 16 01:03:52 1973\n\0