From: Paul Eggert <[EMAIL PROTECTED]>
Subject: Re: shellutils: Question of date command default print format.
> The behavior of the default date command is
> defined: "%a %b %e %H:%M:%S %Z %Y" under locale == C.
> It, however, should change "%c".
> The reason is that POSIX or XPG said
> date command should print LC_TIME format.
>
> There must be some misunderstanding here. The latest official POSIX
> standard (POSIX.2-1992 section 4.15.6.1 page 243 line 3012) specifies
> "%a %b %e %H:%M:%S %Z %Y". And the latest POSIX.2 draft, dated
> 2000-02-29, hasn't changed in this area.
>
> "%c" can't be right since it omits the time zone in the POSIX locale,
> and "date" has always printed the time zone by default.
OK, I agreed with in the POSIX locale. However:
From: Ulrich Drepper <[EMAIL PROTECTED]>
Subject: Re: shellutils: Question of date command default print format.
> > There must be some misunderstanding here. The latest official POSIX
> > standard (POSIX.2-1992 section 4.15.6.1 page 243 line 3012) specifies
> > "%a %b %e %H:%M:%S %Z %Y".
>
> The POSIX standard is only relevant for the C locale. Other loales
> could have different definitions and this is where...
Yes. POSIX and SUSv2 is defined only for the C locale.
It is no description about other locale in standards.
Especially, I cannot your opinion; "date" has always printed
the time zone by default. This is not defined if locale is NOT
set the POSIX, IMHO.
The description of "date" command in the SUSv2;
------------------------------
2.Examples for Denmark, where the default date and time format
is "%a %d %b %Y %T %Z":
$ LANG=da_DK.iso_8859-1 date
ons 02 okt 1991 15:03:32 CET
------------------------------
This is *NOT* the order of "%a %b %e %H:%M:%S %Z %Y", but
"%a %d %b %Y %T %Z".
So I suggest that
* If a system have no locales, or date comman is used in the
POSIX locale, it should work as "%a %b %e %H:%M:%S %Z %Y".
* If a system have locales and it is NOT used in the POSIX locale,
it should display as d_t_fmt.
You may think d_t_fmt have no "%Z" description is the problem.
However, some implementation or locale includes "%Z" in the
context of d_t_fmt (in glibc-2.2, many locales including
en_US have %Z strings in d_t_fmt. I found the interesting
thing that the info and man of date describes:
`%c' -- locale's date and time (Sat Nov 04 12:02:33 EST 1989).
The sample is inappropriate?).
The POSIX and SUSv2 is *ONLY* described in the POSIX locale,
so we don't say "date command without any options should work
printing %Z".
In addition, the reason why I suggested my opinion is that;
we Japanese usually use other order of current date format.
In the Japanese locale, the default behavior of date command
without any options works;
UX/4800 and Solaris7: "%Y %m %d %a %H:%M:%S %Z",
HP-UX10.20 and Digital Unix: "%Y %b %e %H:%M:%S",
IRIX: "%Y %b %e %A %H:%M:%S %Z",
(glibc-2.2: "%Y %m %d %H:%M:%S", this is not proper, IMHO).
The order of "%a %b %e %H:%M:%S %Z %Y" is correct in English,
but *INCORRECT* in some other language/locale like Japanese.
Now another patch:
--- date.c.org Wed Mar 29 03:16:39 2000
+++ date.c Thu Mar 30 07:04:35 2000
@@ -469,6 +469,8 @@
struct tm *tm;
char *out = NULL;
size_t out_length = 0;
+ char *locale_name = NULL;
+ int locale_format = 0;
/* ISO 8601 formats, in local and UTC. See below regarding %z */
static char *iso_format_string[5][2] =
{
@@ -490,13 +492,25 @@
in the RFC format to %Z; this gives, however, an invalid
RFC time format outside the continental United States and GMT. */
+ if(!(locale_name = getenv("LC_TIME")))
+ if(!(locale_name = getenv("LC_ALL")))
+ if(!(locale_name = getenv("LANG")))
+ locale_format = 1;
+ if(locale_name == NULL)
+ locale_format = 1;
+ else if(!strcmp(locale_name, "POSIX") ||
+ !strcmp(locale_name, "C"))
+ locale_format = 1;
+
format = (rfc_format
? (universal_time
? "%a, %_d %b %Y %H:%M:%S GMT"
: "%a, %_d %b %Y %H:%M:%S %z")
: (iso_8601_format
? iso_format_string[iso_8601_format][universal_time]
- : "%a %b %e %H:%M:%S %Z %Y"));
+ : (locale_format
+ ? "%a %b %e %H:%M:%S %Z %Y"
+ : "%c")));
}
else if (*format == '\0')
{
> In Solaris 8, "/usr/bin/date" is equivalent to "/usr/bin/date +%C";
> perhaps this is what you're thinking of? Unfortunately, this violates
> POSIX.2, as POSIX.2 requires that %C expand to the century (currently
> 20). Solaris 8 /usr/xpg4/bin/date conforms to POSIX.2, as does GNU
> date.
I agree.
> It would be nice for the GNU C library's strftime to have a format
> that expands to the current locale's output of "date". This would be
> an extension to the current glibc behavior. This was what Sun tried
> to do with %C. Clearly a different format string should be used,
> though. I suggest %+, as this is what the Olson time zone library
> uses (see ftp://elsie.nci.nih.gov/pub/).
It seems interesting...
Regards,
-- GOTO Masanori
