Yes. D_T_FMT yields a similar output to _DATE_FMT, but it lacks the timezone identifier. So I had thought to use the format specifiers directly and bypass the call to nl_langinfo. I was told that _DATE_FMT was added because Sun made everything up to date with the latest xopen std. I don't yet grok the localization stuff. So, I'm wondering if passing the format specifiers into strftime directly would remove any localizing done by nl_langinfo?

On Thu, Aug 14, 2014 at 7:40 PM, Rich Felker <dalias@libc.org> wrote:

On Thu, Aug 14, 2014 at 07:28:53PM -0400, Alec Salazar wrote:
> I seem to be taking a wrong turn somewhere. Running find . -type f -print0
> | xargs -0 /bin/grep D_FMT in /usr/include for the installed 1.1.4 yields:

> ../langinfo.h:#define D_FMT 0x20029
> ../langinfo.h:#define ERA_D_FMT 0x2002E

> Pulling the latest sources and running the same command in gitdir yields:

> ../src/time/strptime.c: s = strptime(s, nl_langinfo(D_FMT),
> tm);
> ../src/time/strftime.c: item = D_FMT;
> ../include/langinfo.h:#define D_FMT 0x20029
> ../include/langinfo.h:#define ERA_D_FMT 0x2002E

> Neither directory yields a result for DATE_FMT. Am I botching the unix-fu,
> barking up the wrong tree or something else entirely?

Oh, perhaps it's my mistake and the proper name is D_FMT. Or did you
expect _DATE_FMT to give something different from what D_FMT gives?

Also I think you can just use %x directly to get this, rather than
looking it up via nl_langinfo first.

Rich