Re: [v3 PATCH 00/11] Pull Request - changelog

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jan 14, 2018 at 09:02:26PM -0500, J William Piggott wrote:
> On 01/12/2018 05:57 AM, Karel Zak wrote:

> > Well, my mistake. I have thought about "rename --julian to --ordinal"
> > and errx(EXIT_FAILURE, ("use --ordinal, --julian has been deprecated."));
> > 
> > This change is too aggressive without ReleaseNotes warning.
> > 
>  
> I agree, it is aggressive.
> 
> Having considered your comments, I realize that my submissions are
> likely the wrong solutions. The reality is, the practice of calling
> 'ordinal Gregorian calendars' 'Julian calendars' is deeply entrenched;
> it's even in the POSIX standard. 
> 
> So, if we leave the --julian option as it is, what is the solution for
> the name collision. Use some made-up name for a Julian calendar system
> like --caesar. Sometimes Roman is used as an umbrella term for Roman and
> Julian calendars combined. I don't think that's a good choice though,
> because someone may get ambitious and implement output earlier than year
> 1; then it would be necessary to distinguish between Roman and Julian
> calendars. Besides, to muddy the waters further by starting yet another
> practice of using an incorrect name involving Julian just seems wrong.
> 
> I think the new option needs to be called Julian; so the only solution
> left is to use a different name space. I propose the following:
> 
> * leave the current --julian option as is

Unfortunately, this is necessary.

> * add one new option for setting the reform year:
>    --reform-year=<gregorian|iso|julian|1752>

Yes, I think about something like this. It seems like a way how to
keep it extendable.

  * leave the current --julian option as is

  * --reform=<gregorian,1752,greek,...>

  * add --iso (as alias to --reform=gregorian)

> I think this approach would also be better if the other 20 Gregorian
> reform adoption dates are ever added. 24 arguments would be cleaner then
> having an equal number of separate options.

Yes.

> Then to address whether to set the proleptic Gregorian calendar system
> as the default: I think just stay with your original plan, only forget
> the last bullet point with regard to implementing the code; I tried
> including preparations for the switch in the files, but it's too messy. So:
> 
> * leave the current default using 1752 reform
> 
> * create the proleptic Gregorian option
> 
> * let Karel decide if/when/how/politics of changing the default
>   Maybe comments from closing the RedHat bug will help with that choice.
> 
> I mentioned before that I have more bug fixes queued, but didn't want to
> make this patch set to large. Well, some of them influence handling of
> the multiple calendar systems so I may add them to the next version of
> this patch set.

I hope I'll work on cal(1) this week. If you see any bug in the
current code, then fix it again the current master branch. I'll rebase
and merge it to the new code later... or wait ;-)

    Karel

-- 
 Karel Zak  <kzak@xxxxxxxxxx>
 http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux