bug#58494: touch resists date 2022-09-11T00:00:00

[Felix Freeman]

> > In Santiago, Chile, that timestamp does not exist. Is your timezone set 
> > to Santiago time? That would explain your symptoms.
>
> I am, but I don't understand why the timezone would make a time not to
> exist... What am I missing?

Uh, oh, it's daylight saving time change... never thought of that. Good
catch!

Felix Freeman

bug#58494: touch resists date 2022-09-11T00:00:00

[Felix Freeman]

On Thu Oct 13, 2022 at 2:42 PM -03, Paul Eggert wrote:
> On 2022-10-12 18:58, Felix Freeman via GNU coreutils Bug Reports wrote:
> >  $ touch -t 20220911 algo
> >  touch: invalid date format ‘20220911’
> >  $ touch -d 2022-09-11T00:00:00 algo
> >  touch: invalid date format ‘2022-09-11T00:00:00’
>
> In Santiago, Chile, that timestamp does not exist. Is your timezone set 
> to Santiago time? That would explain your symptoms.

I am, but I don't understand why the timezone would make a time not to
exist... What am I missing?

CC = 20
YY = 22
MM = 09
DD = 11
hh = 00
mm = 00

Felix Freeman

bug#58494: touch resists date 2022-09-11T00:00:00

[Paul Eggert]

On 2022-10-12 18:58, Felix Freeman via GNU coreutils Bug Reports wrote:

 $ touch -t 20220911 algo
 touch: invalid date format ‘20220911’
 $ touch -d 2022-09-11T00:00:00 algo
 touch: invalid date format ‘2022-09-11T00:00:00’


In Santiago, Chile, that timestamp does not exist. Is your timezone set 
to Santiago time? That would explain your symptoms.

bug#58494: touch resists date 2022-09-11T00:00:00

[Felix Freeman]

I think I found a bug. In any format that I try to touch a file with the
date 2022-09-11 at 00:00, touch says I'm entering an invalid date
format.

$ touch -t 20220911 algo
touch: invalid date format ‘20220911’
$ touch -d 2022-09-11T00:00:00 algo
touch: invalid date format ‘2022-09-11T00:00:00’

If I change date or hour it works flawlessly

$ touch -d 2022-09-11T01:00:00 algo
$ echo $?
0

Felix Freeman

bug#58476: buggy version sort

[Vincent Lefevre]

On 2022-10-13 10:31:38 +0100, Pádraig Brady wrote:
> This looks to be the same point as discussed in https://bugs.gnu.org/58153
> where a trailing '0' is essentially ignored when sorting,
> as per the debian version sorting spec.
> 
> This is surprising, and perhaps we should diverge from the spec
> in this regard, but I'm not sure.

I doubt very much that having two revisions "upstream_version" and
"upstream_version-0" at the same time is allowed. Since they are
regarded as equivalent, this would confuse the system to decide
which one should be preferred as the latest version.

However, for "sort" or "ls", one may have "foo" and "foo-0" at
the same time, and they need to be sorted. For instance, 0 could
be regarded as an epsilon. So the sorting in my example would be
correct.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#58476: buggy version sort

[Pádraig Brady]

On 12/10/2022 22:07, Vincent Lefevre wrote:

A regression in version sort (used as the natural sort for "ls")
has been introduced from coreutils 8.32 to 9.1:

With coreutils 8.32 (Debian 11):

$ printf "%s\n" a a0 a1 a.b a0.b a1.b | sort -V
a
a.b
a0
a0.b
a1
a1.b

With coreutils 9.1 (Debian/unstable):

$ printf "%s\n" a a0 a1 a.b a0.b a1.b | sort -V
a
a0
a0.b
a.b
a1
a1.b

This is now completely illogical.


This looks to be the same point as discussed in https://bugs.gnu.org/58153
where a trailing '0' is essentially ignored when sorting,
as per the debian version sorting spec.

This is surprising, and perhaps we should diverge from the spec
in this regard, but I'm not sure.

thanks,
Pádraig