Re: [gentoo-dev] Re: RFC: isodate for packages.mask starting on 2019-07-01

2019-07-02 Thread Ulrich Mueller
> On Tue, 02 Jul 2019, Jonas Stein wrote: >> Could you also look into converting other profile files? They were >> known to have even less consistency than top-level package.mask. > Good point. I will have a look at it. > It will take some time, because the date formats there are mixed a

Re: [gentoo-dev] Re: RFC: isodate for packages.mask starting on 2019-07-01

2019-07-02 Thread Jonas Stein
On 01/07/2019 09.30, Michał Górny wrote: > On Mon, 2019-07-01 at 02:29 +0200, Jonas Stein wrote: >> Dear all, >> >>> [..] >>> Change: >>> I suggest that we start using the date format -mm-dd >>> for all dates in package.mask >>> starting with 2019-07-01 >>> [..] >> >> Thank you for your quick

Re: [gentoo-dev] Re: RFC: isodate for packages.mask starting on 2019-07-01

2019-07-01 Thread Michał Górny
On Mon, 2019-07-01 at 02:29 +0200, Jonas Stein wrote: > Dear all, > > > [..] > > Change: > > I suggest that we start using the date format -mm-dd > > for all dates in package.mask > > starting with 2019-07-01 > > [..] > > Thank you for your quick responses. > package.mask uses now ISO 8601

[gentoo-dev] Re: RFC: isodate for packages.mask starting on 2019-07-01

2019-06-30 Thread Jonas Stein
Dear all, > [..] > Change: > I suggest that we start using the date format -mm-dd > for all dates in package.mask > starting with 2019-07-01 > [..] Thank you for your quick responses. package.mask uses now ISO 8601 dates.

Re: [gentoo-dev] Re: RFC: isodate for packages.mask starting on 2019-07-01

2019-06-29 Thread Jonas Stein
Hi Fabian, > I think ISO 8601 date format is an improvement. Great. > However, as you're suggesting to use a date at UTC time, this begs for > scripting, such as the old echangelog did. Absolutely but this is a more complicate step, I want to discuss this later. -- Best, Jonas

[gentoo-dev] Re: RFC: isodate for packages.mask starting on 2019-07-01

2019-06-29 Thread Fabian Groffen
I think ISO 8601 date format is an improvement. However, as you're suggesting to use a date at UTC time, this begs for scripting, such as the old echangelog did. Then, when scripted, the actual date format is no longer an issue. Somehow the current format looks easier to read (for humans) to