Hi,
tomr wrote on Tue, Jan 17, 2017 at 05:47:05PM +1100:
> Could you confirm this, my conclusion in brief: either I need to accept
> reading dates MM/DD/YYYY where ports use the equivalent of %x, or I need
> to rely on ports to present DD/MM/YYYY themselves.
I'm not sure that is correct - it might be, but the wording seems
ambiguous to me.
Here is your choice:
1) Not set LC_TIME nor LC_ALL at all, or set it to en_US.UTF-8.
Then you consistently get MM/DD/YYYY everywhere.
(Except maybe from software that is very broken.)
2) Set LC_TIME or LC_ALL to en_AU.UTF-8.
Then you still get MM/DD/YYYY from base system programs
and libraries.
And you still get MM/DD/YYYY from ports using strftime(3)
and similar functions from base system libraries, even though
the same ports might print DD/MM/YYYY e.g. on FreeBSD.
But you may get DD/MM/YYYY from some ports that implement
their own date formatting without using strftime(3) even on
OpenBSD. So when using a new program, you plainly cannot
know what 01/02/17 means.
If a large program implements multiple versions of date
formatting, some using strftime(3) and some not, you may not
even get consistent output from one program. So seeing
01/17/2017 ONCE from a program is NOT enough to conclude
that this program will always use DD/MM/YYYY.
It sounds weird, but large software is often very sloppily
written and implements the same functionality multiple
times, each time with different bugs.
Your choice.
> The risk of seeing 01/02/17 some places and 02/01/17 other places is
> less of a worry for me personally... after a couple of gotchas I'll be
> able to remember on which side of the road I'm driving where. Or could I
> change *all* dates to drive on the DD/MM/YYYY side of the road?
No, having DD/MM/YYYY everywhere is not supported.
Yours,
Ingo
