Bug#217224: marked as done (libc6-dev: strftime can not return locale-compliant time string without seconds)
Your message dated Thu, 21 Apr 2005 17:53:00 +0900
with message-id <81u0m0340j.wl@omega.webmasters.gr.jp>
and subject line Bug#217224: libc6-dev: strftime can not return locale-compliant time string without seconds
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 23 Oct 2003 12:19:32 +0000
>From pvz@linux.se Thu Oct 23 07:19:32 2003
Return-path: <pvz@linux.se>
Received: from mail.g.bonet.se [212.181.52.4]
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1ACeR9-0002AI-00; Thu, 23 Oct 2003 07:19:31 -0500
Received: from tanya (mail@as14-6-3.o.s.bonet.se [217.215.216.100])
by mail.g.bonet.se (8.12.9/8.12.9) with ESMTP id h9NCGihS075273;
Thu, 23 Oct 2003 14:16:45 +0200 (CEST)
(envelope-from pvz@linux.se)
Received: from pvz by tanya with local (Exim 3.36 #1 (Debian))
id 1ACeR1-0002kX-00; Thu, 23 Oct 2003 14:19:23 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
From: Per von Zweigbergk <pvz@e.kth.se>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: libc6-dev: strftime can not return locale-compliant time string without
seconds
X-Mailer: reportbug 2.34
Date: Thu, 23 Oct 2003 14:19:23 +0200
Message-Id: <E1ACeR1-0002kX-00@tanya>
Sender: Per von Zweigbergk <pvz@linux.se>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mail.g.bonet.se id h9NCGihS075273
Delivered-To: submit@bugs.debian.org
X-Spam-Status: No, hits=-6.0 required=4.0
tests=BAYES_30,HAS_PACKAGE
version=2.53-bugs.debian.org_2003_10_21
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_10_21 (1.174.2.15-2003-03-30-exp)
Package: libc6-dev
Version: 2.3.2-8
Severity: wishlist
In a program I was developing, I had the need to represent time in a
localized fashion. Since the program in question deals with start and
stop times of television programmes, it makes no sense to clutter the
interface by specifying which second the programme starts on.
I attempted to use strftime(), but I could only find %X, which returns
the preferred time representation for the current locale, without the
date. It returns hours, minutes, and seconds on all locales I tested
this on.
There is also %R and %r, but for one using them is to ignore any
12/24-hour preference in the locale. (I'm assuming such a property
exists.) They also ignore the preferred seperator between the hours and
the minutes part. In Swedish, for example, we prefer to seperate hours
and minutes with a . -- so the appropriate formatting for Swedish would
be "16.45", for example, while %R would return "16:45".
I'm not a native speaker of the French language, but I am told they use
the convention "16h45" in situations such as this. I'm sure there are
many other examples of separator characters. Also, different languages
have different conventions for whether leading zeroes should be used
before single-digit hours, and whether a 12 hour or a 24 hour convention
should be used.
For this reason, I suggest that a new format be added that displays the
time in a representation suitable for the particular locale, but without
seconds.
Of course, as with any new feature in libc, the feature can't be used
safely without breaking backward-compatibility. Still, it's better to be
late than never adding a feature such as this.
In the meantime, I have decided to use gettext to allow translators to
compose their own format strings in the program I'm developing.
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux tanya 2.4.20 #1 m=E5n mar 31 19:30:02 CEST 2003 i686
Locale: LANG=3Dsv_SE.UTF-8, LC_CTYPE=3Dsv_SE.UTF-8
Versions of packages libc6-dev depends on:
ii libc6 2.3.2-8 GNU C Library: Shared librar=
ies an
-- no debconf information
---------------------------------------
Received: (at 217224-done) by bugs.debian.org; 21 Apr 2005 08:53:02 +0000
>From gotom@debian.or.jp Thu Apr 21 01:53:02 2005
Return-path: <gotom@debian.or.jp>
Received: from omega.webmasters.gr.jp (webmasters.gr.jp) [218.44.239.78]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1DOXQk-0002mx-00; Thu, 21 Apr 2005 01:53:02 -0700
Received: from omega.webmasters.gr.jp (localhost [127.0.0.1])
by webmasters.gr.jp (Postfix) with ESMTP
id DC4E2DEB1E; Thu, 21 Apr 2005 17:53:00 +0900 (JST)
Date: Thu, 21 Apr 2005 17:53:00 +0900
Message-ID: <81u0m0340j.wl@omega.webmasters.gr.jp>
From: GOTO Masanori <gotom@debian.or.jp>
To: Per von Zweigbergk <pvz@e.kth.se>, 217224-done@bugs.debian.org
Subject: Re: Bug#217224: libc6-dev: strftime can not return locale-compliant time string without seconds
In-Reply-To: <E1ACeR1-0002kX-00@tanya>
References: <E1ACeR1-0002kX-00@tanya>
User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya)
FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
(i386-debian-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Delivered-To: 217224-done@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
At Thu, 23 Oct 2003 14:19:23 +0200,
Per von Zweigbergk wrote:
> In a program I was developing, I had the need to represent time in a
> localized fashion. Since the program in question deals with start and
> stop times of television programmes, it makes no sense to clutter the
> interface by specifying which second the programme starts on.
>
> I attempted to use strftime(), but I could only find %X, which returns
> the preferred time representation for the current locale, without the
> date. It returns hours, minutes, and seconds on all locales I tested
> this on.
>
> There is also %R and %r, but for one using them is to ignore any
> 12/24-hour preference in the locale. (I'm assuming such a property
> exists.) They also ignore the preferred seperator between the hours and
> the minutes part. In Swedish, for example, we prefer to seperate hours
> and minutes with a . -- so the appropriate formatting for Swedish would
> be "16.45", for example, while %R would return "16:45".
>
> I'm not a native speaker of the French language, but I am told they use
> the convention "16h45" in situations such as this. I'm sure there are
> many other examples of separator characters. Also, different languages
> have different conventions for whether leading zeroes should be used
> before single-digit hours, and whether a 12 hour or a 24 hour convention
> should be used.
Almost all coversion characters (ex: %c) in strftime are defined in
POSIX. Each locale defines locale-specific conversion data; you can
see it: "info libc" "7.6.2 Pinpoint Access to Locale Data".
> For this reason, I suggest that a new format be added that displays the
> time in a representation suitable for the particular locale, but without
> seconds.
>
> Of course, as with any new feature in libc, the feature can't be used
> safely without breaking backward-compatibility. Still, it's better to be
> late than never adding a feature such as this.
>
> In the meantime, I have decided to use gettext to allow translators to
> compose their own format strings in the program I'm developing.
If glibc locale definition is not fit for your requirement, using
gettext is good idea.
We don't have any plan to add such new interface - because it's
defined in the POSIX/SUS/ISO standards. Introducing new conversion
character may be conflicted with the future standards. I close this
report. If you disagree with this closing, and if you still want such
new conversion character, please reopen it after you discuss with the
standard committee especially for ISO.
Regards,
-- gotom
Reply to: