| Message ID | 1478202401-5238-1-git-send-email-P@draigBrady.com |
|---|---|
| State | New, archived |
| Headers |
Received: (qmail 13990 invoked by alias); 3 Nov 2016 19:46:56 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 13973 invoked by uid 89); 3 Nov 2016 19:46:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=Quarter, quarter X-HELO: mail2.vodafone.ie X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4JAIceUldtT4V7/2dsb2JhbABegzoihCe1YIQJhhKBNkwBAQEBAQFmJ4RIFhVSKIFLiBGnL5tlhS+KUYF9C0CCRgWYRY4miVaFQgKPUlSBNgEBCIIuPIpEAQEB From: =?UTF-8?q?P=C3=A1draig=20Brady?= <P@draigBrady.com> To: libc-alpha@sourceware.org Cc: =?UTF-8?q?P=C3=A1draig=20Brady?= <P@draigBrady.com> Subject: [PATCH] strftime: support %q to output the quarter of year Date: Thu, 3 Nov 2016 19:46:41 +0000 Message-Id: <1478202401-5238-1-git-send-email-P@draigBrady.com> |
Commit Message
Pádraig Brady
Nov. 3, 2016, 7:46 p.m. UTC
This is already supported by gnulib. * manual/time.texi: Document %q outputs quarter 1..4. * time/strftime_l.c: Implement %q. --- manual/time.texi | 6 ++++++ time/strftime_l.c | 4 ++++ 2 files changed, 10 insertions(+)
Comments
* Pádraig Brady: > This is already supported by gnulib. This needs a test case (at least a test case update). > + case L_('q'): /* GNU extension. */ > + DO_SIGNED_NUMBER (1, tp->tm_mon < -3, tp->tm_mon / 3 + 1U); > + break; I don't think we have DO_SIGNED_NUMBER in glibc.
On 03/11/2016 17:58, Florian Weimer wrote: > * Pádraig Brady: > >> This is already supported by gnulib. > > This needs a test case (at least a test case update). > >> + case L_('q'): /* GNU extension. */ >> + DO_SIGNED_NUMBER (1, tp->tm_mon < -3, tp->tm_mon / 3 + 1U); >> + break; > > I don't think we have DO_SIGNED_NUMBER in glibc. > Indeed and you need to indicate how/where exactly you have tested it.
On Thu, 3 Nov 2016, Florian Weimer wrote: > * Pádraig Brady: > > > This is already supported by gnulib. > > This needs a test case (at least a test case update). And a NEWS entry.
Hi, Shouldn't strptime() family also support the same? Regards, Rafal
On 03/11/16 19:46, Pádraig Brady wrote:
> This is already supported by gnulib.
why?
On 04/11/16 11:41, Szabolcs Nagy wrote: > On 03/11/16 19:46, Pádraig Brady wrote: >> This is already supported by gnulib. > why? It's a marginal benefit, but as noted in the cover of my updated patch: "Note even though the code is trivial here, %q is useful from the shell as there you need to: $(( ($(date +%-m)-1)/3+1 ))". I'll add that to the actual commit.
On 04/11/16 12:00, Pádraig Brady wrote: > On 04/11/16 11:41, Szabolcs Nagy wrote: >> On 03/11/16 19:46, Pádraig Brady wrote: >>> This is already supported by gnulib. > >> why? > > It's a marginal benefit, but as > noted in the cover of my updated patch: > > "Note even though the code is trivial here, > %q is useful from the shell as there you need to: > $(( ($(date +%-m)-1)/3+1 ))". > > I'll add that to the actual commit. this can conflict with future standard, so there need to be a strong reason for adding such extensions to portability libraries such as gnulib or to c runtimes. how does gnulib plan to deal with the conflict once posix adds %q with different meaning?
On 04/11/16 12:07, Szabolcs Nagy wrote: > On 04/11/16 12:00, Pádraig Brady wrote: >> On 04/11/16 11:41, Szabolcs Nagy wrote: >>> On 03/11/16 19:46, Pádraig Brady wrote: >>>> This is already supported by gnulib. >> >>> why? >> >> It's a marginal benefit, but as >> noted in the cover of my updated patch: >> >> "Note even though the code is trivial here, >> %q is useful from the shell as there you need to: >> $(( ($(date +%-m)-1)/3+1 ))". >> >> I'll add that to the actual commit. > > this can conflict with future standard, so > there need to be a strong reason for adding > such extensions to portability libraries > such as gnulib or to c runtimes. > > how does gnulib plan to deal with the conflict > once posix adds %q with different meaning? Perl's date lib also uses %q for quarter. So between that and gnulib (and glibc?) POSIX would be unlikely to choose %q for something else. In any case I intend to propose it to the POSIX folks. thanks, Pádraig
On 04/11/16 12:23, Pádraig Brady wrote: > On 04/11/16 12:07, Szabolcs Nagy wrote: >> On 04/11/16 12:00, Pádraig Brady wrote: >>> On 04/11/16 11:41, Szabolcs Nagy wrote: >>>> On 03/11/16 19:46, Pádraig Brady wrote: >>>>> This is already supported by gnulib. >>> >>>> why? >>> >>> It's a marginal benefit, but as >>> noted in the cover of my updated patch: >>> >>> "Note even though the code is trivial here, >>> %q is useful from the shell as there you need to: >>> $(( ($(date +%-m)-1)/3+1 ))". >>> >>> I'll add that to the actual commit. >> >> this can conflict with future standard, so >> there need to be a strong reason for adding >> such extensions to portability libraries >> such as gnulib or to c runtimes. >> >> how does gnulib plan to deal with the conflict >> once posix adds %q with different meaning? > > Perl's date lib also uses %q for quarter. i don't know what "Perl's date lib" is, the perl DateTime module does not seem to support %q. https://metacpan.org/pod/DateTime#strftime-Patterns > So between that and gnulib (and glibc?) > POSIX would be unlikely to choose %q for something else. > In any case I intend to propose it to the POSIX folks. > > thanks, > Pádraig >
On 04/11/16 12:41, Szabolcs Nagy wrote: > On 04/11/16 12:23, Pádraig Brady wrote: >> On 04/11/16 12:07, Szabolcs Nagy wrote: >>> On 04/11/16 12:00, Pádraig Brady wrote: >>>> On 04/11/16 11:41, Szabolcs Nagy wrote: >>>>> On 03/11/16 19:46, Pádraig Brady wrote: >>>>>> This is already supported by gnulib. >>>> >>>>> why? >>>> >>>> It's a marginal benefit, but as >>>> noted in the cover of my updated patch: >>>> >>>> "Note even though the code is trivial here, >>>> %q is useful from the shell as there you need to: >>>> $(( ($(date +%-m)-1)/3+1 ))". >>>> >>>> I'll add that to the actual commit. >>> >>> this can conflict with future standard, so >>> there need to be a strong reason for adding >>> such extensions to portability libraries >>> such as gnulib or to c runtimes. >>> >>> how does gnulib plan to deal with the conflict >>> once posix adds %q with different meaning? >> >> Perl's date lib also uses %q for quarter. > > i don't know what "Perl's date lib" is, > the perl DateTime module does not seem to support %q. > https://metacpan.org/pod/DateTime#strftime-Patterns Sorry Perl's Date::Format supports %q https://metacpan.org/pod/Date::Format#CONVERSION-SPECIFICATION
ISO 30112 will poropose %q in the new revision. I think it is difficult for POSIX then to do something else. Have you got standardese for the %q spec, which I can use in 30112? Best regards keld On Fri, Nov 04, 2016 at 12:23:28PM +0000, Pádraig Brady wrote: > On 04/11/16 12:07, Szabolcs Nagy wrote: > > On 04/11/16 12:00, Pádraig Brady wrote: > >> On 04/11/16 11:41, Szabolcs Nagy wrote: > >>> On 03/11/16 19:46, Pádraig Brady wrote: > >>>> This is already supported by gnulib. > >> > >>> why? > >> > >> It's a marginal benefit, but as > >> noted in the cover of my updated patch: > >> > >> "Note even though the code is trivial here, > >> %q is useful from the shell as there you need to: > >> $(( ($(date +%-m)-1)/3+1 ))". > >> > >> I'll add that to the actual commit. > > > > this can conflict with future standard, so > > there need to be a strong reason for adding > > such extensions to portability libraries > > such as gnulib or to c runtimes. > > > > how does gnulib plan to deal with the conflict > > once posix adds %q with different meaning? > > Perl's date lib also uses %q for quarter. > So between that and gnulib (and glibc?) > POSIX would be unlikely to choose %q for something else. > In any case I intend to propose it to the POSIX folks. > > thanks, > Pádraig
On 04/11/16 13:12, keld@keldix.com wrote: > ISO 30112 will poropose %q in the new revision. > I think it is difficult for POSIX then to do something else. this should be the other way around: propose the interface to posix, then add locale specifications later, otherwise the two standards can diverge.
On 04/11/2016 12:12, Szabolcs Nagy wrote: > On 04/11/16 13:12, keld@keldix.com wrote: >> ISO 30112 will poropose %q in the new revision. >> I think it is difficult for POSIX then to do something else. > > this should be the other way around: propose the interface > to posix, then add locale specifications later, otherwise > the two standards can diverge. I tend to agree with this rationale.
On Fri, Nov 04, 2016 at 02:12:28PM +0000, Szabolcs Nagy wrote: > On 04/11/16 13:12, keld@keldix.com wrote: > > ISO 30112 will poropose %q in the new revision. > > I think it is difficult for POSIX then to do something else. > > this should be the other way around: propose the interface > to posix, then add locale specifications later, otherwise > the two standards can diverge. Oh, well, 30112 has taken the lead on many i18n issues, and this is also the agreement with the posix folks. Best regards keld
diff --git a/manual/time.texi b/manual/time.texi index 8a5f94e..f4c5f87 100644 --- a/manual/time.texi +++ b/manual/time.texi @@ -1510,6 +1510,12 @@ most locales @samp{AM}/@samp{PM} format is not supported, in such cases This format is a GNU extension. +@item %q +Quarter of the year (@samp{1}@dots{}@samp{4}), +with January starting the first quarter. + +This format is a GNU extension. + @item %r The complete calendar time using the AM/PM format of the current locale. diff --git a/time/strftime_l.c b/time/strftime_l.c index 869e0b9..13db490 100644 --- a/time/strftime_l.c +++ b/time/strftime_l.c @@ -1108,6 +1108,10 @@ __strftime_internal (s, maxsize, format, tp, tzset_called ut_argument goto underlying_strftime; #endif + case L_('q'): /* GNU extension. */ + DO_SIGNED_NUMBER (1, tp->tm_mon < -3, tp->tm_mon / 3 + 1U); + break; + case L_('R'): subfmt = L_("%H:%M"); goto subformat;