On 2019-08-10 9:17 p.m., Assaf Gordon wrote:
On Sat, Aug 10, 2019 at 01:05:23PM -0700, Paul Eggert wrote:
The attached patch-set includes this fix,
and the updated NEWS wording.
(I'll wait until gnulib is updated with the additional fix,
then create a new coreutil patch with the latest gnulib.)
On Sat, Aug 10, 2019 at 01:05:23PM -0700, Paul Eggert wrote:
> > The attached patch-set includes this fix,
> > and the updated NEWS wording.
> > (I'll wait until gnulib is updated with the additional fix,
> > then create a new coreutil patch with the latest gnulib.)
>
> Thanks here too; it all
Assaf Gordon wrote:
Attached suggested follow-up patch for gnulib.
Thanks for catching that; I installed it into Gnulib after updating the
ChangeLog entry slightly (and commit message to match).
The attached patch-set includes this fix,
and the updated NEWS wording.
(I'll wait until
Hello,
(adding bug-gnulib again :) )
Thank you both for the review and suggestions.
On 2019-08-10 1:46 a.m., Paul Eggert wrote:
> Assaf Gordon wrote:
>> I suggest the attached patch for coreutils.
>
> OK, except I'd remove "in accordance with rfc5322" since RFC 5322
> recommends treating all
[removing bug-gnulib]
On 8/10/19 4:26 AM, Assaf Gordon wrote:
> This results in a user-visible change for gnu date,
> I suggest the attached patch for coreutils.
Thanks, the tests look good.
The gnulib update requires the attached to calm down sc_po_check.
You may squash that into your gnulib
Assaf Gordon wrote:
I suggest the attached patch for coreutils.
OK, except I'd remove "in accordance with rfc5322" since RFC 5322 recommends
treating all these zones as if they were UTC. Also, "T" continues to have its
military meaning (i.e., between "S" and "U") if it's used properly.
Hello,
On Fri, Aug 09, 2019 at 02:01:35PM -0700, Paul Eggert wrote:
> Since the RFC 822 error was fixed in 2001 when RFC 2822 came out, it is long
> past time to fix parse-datetime.y accordingly, so I installed the attached
> patch into Gnulib.
This results in a user-visible change for gnu date,
