Red Hat Bugzilla – Bug 749704
date cannot easily produce lower case formatted output
Last modified: 2016-05-11 03:57:06 EDT
Description of problem:
Suppose ones want lower case abbreviated day-of-week names. By default %a produces capitalized names, eg Fri. Using %^a correctly produces upper case. Using %#a unfortunately produces the same as %^A, ie. FRI. Quite clearly FRI is not the opposite case of Fri. Instead of an 'opposite case' modifier (which seems to be quite useless because the case of the normal output is already definitively known) there should be a pure lower case modifier.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. date +%a
2. date +^a
3. date +#a
4. date +%/a
In above I have chosen a / modifier for lower case (only because it almost looks like a lower case 'l', and doesn't need any shell escape). Also,
a proper lower case modifier obsoletes the %P (which should never have been implemented that way - modifiers are for modifying, alpha characters are for unique formats - but that is an error in strftime(3) which coreutils/date imitates).
Yet again, it looks like I am the only person left on the planet who uses 'date' and bothers to file a bug report. If this report meets with the usual 'you should file upstream' or 'not a bug' then this will be the last bug report I ever file ... and then I will join the other happy people who never waste their valuable time filing bug reports.
Thanks for the suggestion. Seems to be reasonable and as these "flags" are GNU extension anyway, upstream probably could accept that. To be honest, I would expect the combination of %#^a producing lowercase - as these are documented as flags - so should be possible to combine them. However - change_case (#) just sets lower_case flag to false and upper_case flag to true in the %a case.
To your last paragraph:
No, you are not the only person left on the planet who uses 'date' and bothers to file a bug report - actually last week I had two other 'date' command reports (1 NOTABUG and 1 ended in kernel).
Yes, this is one of the reports which are better to be reported upstream - as this is request for enhancement and you could provide better usecases/arguments to support the flag addition.
Your bug reports are always without patches - and usually some corner case changes in behaviour or RFEs - which always mean a bit lower priority for Fedora maintainers - and you quite often use not very polite tone when the Fedora package maintainer (who usually works on the Fedora packages in his/her spare time) is not excited by your idea (or even closes the request as not a bug).
In this case, change will probably be just few lines (two lines change in lib/strftime.c, one or two lines in coreutils.texi and probably one line in one of tests) - but in some cases your requests were about more complex things.