replace _DATE_FMT with format specifiers

[salazaj]

Bring into conformance with Open Group Base Specifications. Or bypass nl_langinfo to pass the format specifiers directly and conform to ISO.

[salazaj]

output of print_timestamp(1) and print_timestamp(2) from lib/libspl/timestamp.c

D_T_FMT 1408023168
DATE_FMT 1408023168
D_T_FMT Thu Aug 14 09:32:48 2014
DATE_FMT Thu Aug 14 09:32:48 EDT 2014

assigning fmt the format specifiers directly can yield the timezone, although at the end

fmt = "%c %Z";:  1408028529
_DATE_FMT: 1408028529
fmt = "%c %Z";:  Thu Aug 14 11:02:09 2014 EDT
_DATE_FMT: Thu Aug 14 11:02:09 EDT 2014

[behlendorf]

If the Illumos code is to be believed then _DATE_FMT was added for XPG4 (XSH4) compliance. And then fairly recently GNU picked it up as an extension, https://sourceware.org/ml/newlib/2010/msg00152.html. Presumably, this causes build failures in a different environment?

[salazaj]

Yes, I'm trying to address #2567. I don't know about the other libc's but I would suspect similar behavior. I have to say, the link you gave is a bit over my head. Does this mean that bypassing nl_langinfo is not an option?

[salazaj]

Ok, so if I understand this right. nl_langinfo is needed vice passing the format specifiers directly to allow for localization before going to strftime? Would a call to setlocale suffice instead?

[salazaj]

Or would it be preferable to add something like this:

#ifndef _XOPEN_XPG4
#define _DATE_FMT D_T_FMT
#endif /* _XOPEN_XPG4 */

[salazaj]

I'd rather not clutter up the code base with this sort of thing. So I'll close the pull request and leave this alone unless you think this needs to be addressed.

[behlendorf]

@salazaj It might be a problem for other libc's depending on what they support. But until we find such a version of libc I'd suggest sticking with the existing implementation.