On Wed, 22 Jul 2020, Geoff Clare wrote:
Another reason we can't change the required d_t_fmt value for the
POSIX (aka C) locale is because it would introduce a conflict with the
C standard, which requires (in the strftime() description) that for
the C locale %c is equivalent to %a %b %e %T
J William Piggott wrote, on 21 Jul 2020:
>
> On Mon, 13 Jul 2020, Geoff Clare wrote:
>
> > J William Piggott wrote, on 12 Jul 2020:
> > >
> > > On Mon, 6 Jul 2020, Geoff Clare wrote:
> > >
> > > > There is no way we are going to change the required d_t_fmt value for
> > > > the POSIX locale.
While %Z is part of strftime() in the c2x draft (strptime() is not present at
all), it's specification is left as implementation-defined, therefore
non-portable enough to be still considered unspecified, for the "C" locale.
Additionally, the format %c represents for the "C", and by extension
On Mon, 13 Jul 2020, Eric Blake wrote:
On 7/13/20 4:07 AM, Geoff Clare wrote:
J William Piggott wrote, on 12 Jul 2020:
On Mon, 6 Jul 2020, Geoff Clare wrote:
There is no way we are going to change the required d_t_fmt value for
the POSIX locale.
Why?
Because every implementation
On Sun, 12 Jul 2020, shwaresyst wrote:
Thank you for replying.
The reason for the disconnect, that I see, is because the %Z modifier
references the TZ environment variable, not a value in a struct tm, adding it
to d_t_fmt would disqualify the definition from being __STD_C__ conforming.
On Mon, 13 Jul 2020, Geoff Clare wrote:
J William Piggott wrote, on 12 Jul 2020:
On Mon, 6 Jul 2020, Geoff Clare wrote:
There is no way we are going to change the required d_t_fmt value for
the POSIX locale.
Why?
Because every implementation would have to change, and all
On 7/13/20 4:07 AM, Geoff Clare wrote:
J William Piggott wrote, on 12 Jul 2020:
On Mon, 6 Jul 2020, Geoff Clare wrote:
There is no way we are going to change the required d_t_fmt value for
the POSIX locale.
Why?
Because every implementation would have to change, and all applications
J William Piggott wrote, on 12 Jul 2020:
>
> On Mon, 6 Jul 2020, Geoff Clare wrote:
>
> > There is no way we are going to change the required d_t_fmt value for
> > the POSIX locale.
>
> Why?
Because every implementation would have to change, and all applications
that rely on the current value
The reason for the disconnect, that I see, is because the %Z modifier
references the TZ environment variable, not a value in a struct tm, adding it
to d_t_fmt would disqualify the definition from being __STD_C__ conforming.
This is one of the areas where the C standard can be considered
On Mon, 6 Jul 2020, Geoff Clare wrote:
J William Piggott wrote, on 05 Jul 2020:
--
(0004893) geoffclare (manager) - 2020-07-02 10:57
https://austingroupbugs.net/view.php?id=1345#c4893
J William Piggott wrote, on 05 Jul 2020:
>
> > I disagree. The standard defines what each of the conversion
> > specifiers is converted to. So the Denmark example demonstrates a
> > typical result of a %a conversion, a %d conversion, ..., and a %Z
> > conversion for a da_DK locale.
>
> "what
On Thu, 2 Jul 2020, Austin Group Bug Tracker wrote:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1345
==
Reported By:
On Tue, 23 Jun 2020, Geoff Clare wrote:
J William Piggott wrote, on 22 Jun 2020:
On Mon, 22 Jun 2020, Geoff Clare wrote:
J William Piggott wrote, on 21 Jun 2020:
On Fri, 5 Jun 2020, Geoff Clare wrote:
J William Piggott wrote, on 05 Jun 2020:
On Tue, 26 May 2020, Geoff Clare
J William Piggott wrote, on 22 Jun 2020:
>
> On Mon, 22 Jun 2020, Geoff Clare wrote:
>
> >J William Piggott wrote, on 21 Jun 2020:
> >>
> >>On Fri, 5 Jun 2020, Geoff Clare wrote:
> >>
> >>>J William Piggott wrote, on 05 Jun 2020:
>
> On Tue, 26 May 2020, Geoff Clare wrote:
>
>
On Sun, 21 Jun 2020, shwaresyst wrote:
Re: Are not the examples demonstrating relevant date utility specification
requirments as follows:
No, they are examples of how the various specified elements can produce output
reflecting various locale LC_TIME settings, that's all. The actual format
On Mon, 22 Jun 2020, Geoff Clare wrote:
J William Piggott wrote, on 21 Jun 2020:
On Fri, 5 Jun 2020, Geoff Clare wrote:
J William Piggott wrote, on 05 Jun 2020:
On Tue, 26 May 2020, Geoff Clare wrote:
==
J William Piggott wrote, on 21 Jun 2020:
>
> On Fri, 5 Jun 2020, Geoff Clare wrote:
>
> >J William Piggott wrote, on 05 Jun 2020:
> >>
> >> On Tue, 26 May 2020, Geoff Clare wrote:
> >>
> >> >>==
> >>
Re: Are not the examples demonstrating relevant date utility specification
requirments as follows:
No, they are examples of how the various specified elements can produce output
reflecting various locale LC_TIME settings, that's all. The actual format
string is still an unspecified
On Fri, 5 Jun 2020, Geoff Clare wrote:
J William Piggott wrote, on 05 Jun 2020:
>
> On Tue, 26 May 2020, Geoff Clare wrote:
>
> >>==
> >>https://www.austingroupbugs.net/view.php?id=1345
>
There is also the POSIX locale is a superset of the C locale as defined by the
C standard, because it requires support of the Portable Character Set, which
has more chars than C requires, and has the LC_MESSAGES category; as primary
differences.
On Wednesday, June 10, 2020 Joerg Schilling
On 6/8/2020 2:39 AM, Schwarz, Konrad wrote:
-Original Message-
From: Larry Dwyer
The purpose of the POSIX locale is mandatory so that a conformance suite can be
developed for the purpose of testing and branding a
manufacturer's system for POSIX conformance (period).
Hmm, isn't it
> -Original Message-
> From: Larry Dwyer
> The purpose of the POSIX locale is mandatory so that a conformance suite can
> be developed for the purpose of testing and branding a
> manufacturer's system for POSIX conformance (period).
Hmm, isn't it also so that applications can make more
Hi Willie,
The example sections of the standard are "informative" not "normative".
They do not affect conformance to the "standard". You will find the
definition of "informative" and "normative" within the Single UNIX
Specification.
In this case, these examples demonstrate that, if the user
J William Piggott wrote, on 05 Jun 2020:
>
> On Tue, 26 May 2020, Geoff Clare wrote:
>
> >>==
> >>https://www.austingroupbugs.net/view.php?id=1345
> >>==
> >
>
On Tue, 26 May 2020, Geoff Clare wrote:
==
https://www.austingroupbugs.net/view.php?id=1345
==
Summary:date(1) default format
...
Hi Alan,
Thanks for your rapid and detailed response. I appreciate that you made
the extra effort to included the SCCS comments.
I should be able to trigger a resolution to this defect report after I
have an opportunity to close with the originator.
Cheers,
Larry
On 5/29/2020 2:02 PM,
On 5/28/20 10:03 PM, Larry Dwyer wrote:
To anyone at Oracle Inc. on this mailing list:
I have gone through my library and found only one reference to date_fmt. It is
in the proceedings of the Tenth International Unicode Conference. It is in an
informative discussion about locale
To anyone at Oracle Inc. on this mailing list:
I have gone through my library and found only one reference to date_fmt.
It is in the proceedings of the Tenth International Unicode
Conference. It is in an informative discussion about locale performance
as measured on Solaris. It is in the
Hi Geoff,
I was already working with William to research XPG[234] behind the scenes.
Unfortunately, my copies of the various standards were in such condition
and organization that it was taking me more research time than might be
consumed by someone who has them neatly arranged in a bookshelf
Geoff Clare wrote:
> I believe that leaving the default format unspecified, except for the
> POSIX locale, was intentional. The same approach was taken for many
> other utilities whose behaviour is affected by locale settings.
I guess that there are too many languages, that differ from the
> ==
> https://www.austingroupbugs.net/view.php?id=1345
> ==
> Summary:date(1) default format
> Description:
> PREFACE
> For simplicity I
On Mon, 25 May 2020, Larry Dwyer wrote:
Hi Willie,
The quotes you attribute to XPG3 are actually from XPG4.
Do you have access to XPG3? If yes, could you send me the items that I
requested from it?
Yes, the string you quote below:
3012 date "+%a %b %e %H:%M:%S %Z %Y"
Is in XPG4 and it's
Hi Willie,
The quotes you attribute to XPG3 are actually from XPG4. It was my
fault that I did not make this clear to you when I sent the quotes from
my library. In another part of XPG4, it is stated that the XPG4 is
aligned with the (newly) published POSIX 1003.2, 1992.
The P1003.2
33 matches
Mail list logo
