NetBSD Problem Report #40337

From www@NetBSD.org  Wed Jan  7 16:16:14 2009
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 70C6563B938
	for <gnats-bugs@gnats.netbsd.org>; Wed,  7 Jan 2009 16:16:14 +0000 (UTC)
Message-Id: <20090107161614.2EF3263B8C6@narn.NetBSD.org>
Date: Wed,  7 Jan 2009 16:16:14 +0000 (UTC)
From: mm_lists@pulsar-zone.net
Reply-To: mm_lists@pulsar-zone.net
To: gnats-bugs@NetBSD.org
Subject: Proposed localized change to w(1)/uptime(1)
X-Send-Pr-Version: www-1.0

>Number:         40337
>Category:       bin
>Synopsis:       Proposed localized change to w(1)/uptime(1)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 07 16:20:00 +0000 2009
>Last-Modified:  Sun Feb 15 19:30:08 +0000 2009
>Originator:     Matthew Mondor
>Release:        netbsd-5, -current (5.99.x)
>Organization:
>Environment:
>Description:
w/uptime uses a custom time output function using strftime(3) %l and %p rather than %X which should output better localized time.  Unless there is an output standard uptime/w must abide to (I do not think so), I propose the following minor fix.

>How-To-Repeat:

>Fix:
--- ./w.c.orig  2009-01-07 11:09:11.000000000 -0500
+++ w.c 2009-01-07 11:10:49.000000000 -0500
@@ -492,7 +492,7 @@
         * SCCS forces the string manipulation below, as it replaces
         * %, M, and % in a character string with the file name.
         */
-       (void)strftime(buf, sizeof(buf), "%l:%" "M%p", localtime(nowp));
+       (void)strftime(buf, sizeof(buf), "%X", localtime(nowp));
        buf[sizeof(buf) - 1] = '\0';
        (void)printf("%s ", buf);

>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/40337: Proposed localized change to w(1)/uptime(1)
Date: Sat, 14 Feb 2009 22:33:43 +0000

 On Wed, Jan 07, 2009 at 04:20:00PM +0000, mm_lists@pulsar-zone.net wrote:
  > w/uptime uses a custom time output function using strftime(3) %l
  > and %p rather than %X which should output better localized time.
  > Unless there is an output standard uptime/w must abide to (I do not
  > think so), I propose the following minor fix.

 So, because this changes the default output formatting in a program
 that's fairly often used in scripts, I don't think it's a great idea.

 Unfortunately, strftime does not define a "short time" format that
 would naturally produce %l:%M%p in the default locale. Probably it
 should, but we don't really get to decide that.

 Maybe a suitable hack would be to teach w which locales want %k:%M
 instead of %l:%M%p? Is there any other alternative formatting that
 anyone might (reasonably) want?

 -- 
 David A. Holland
 dholland@netbsd.org

From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: dholland-bugs@NetBSD.org
Subject: Re: bin/40337: Proposed localized change to w(1)/uptime(1)
Date: Sun, 15 Feb 2009 00:11:12 -0500

 On Sat, 14 Feb 2009 22:35:02 +0000 (UTC)
 David Holland <dholland-bugs@netbsd.org> wrote:

 >  So, because this changes the default output formatting in a program
 >  that's fairly often used in scripts, I don't think it's a great idea.

 True, this makes it a bit more complex

 >  Unfortunately, strftime does not define a "short time" format that
 >  would naturally produce %l:%M%p in the default locale. Probably it
 >  should, but we don't really get to decide that.
 >  Maybe a suitable hack would be to teach w which locales want %k:%M
 >  instead of %l:%M%p? Is there any other alternative formatting that
 >  anyone might (reasonably) want?

 %X wouldn't be suitable for that "short time"?

 I just checked what might be ideal for scripts but I'm surprised
 uptime(1) doesn't allow date(1)-like format argument using strftime(3),
 an argument to chose between 24h/12h time nor an argument to return the
 uptime expressed in seconds.  Assuming these would exist, scripts would
 no longer need to parse locale-specific output...

 I checked on a Debian system and uptime appears to return the C/POSIX
 LC_TIME format with any locale set:
 23:33:03 up 2 days,  3:18,  3 users,  load average: 0.14, 0.05, 0.01

 Versus ours:
 11:34PM  up 3 days,  4:07, 8 users, load averages: 0.03, 0.02, 0.00

 I couldn't check the output on OpenBSD and FreeBSD.  It should be noted
 that the proposed change affects the returned current time and not the
 actual uptime output, for which scripts may already use date(1)...
 Some might still argue that under some locales a comma should be used
 instead of a dot (i.e. LC_NUMERIC=fr_CA) for load averages, but this
 change wouldn't address this.

 I actually have no strong opinion about this however, I filed the PR
 after noticing a complaint from a user on IRC.  If it makes better
 sense not to localize uptime or w output let's leave them as-is, of
 course.

 Admitedly, there are many non-localized cases in the base system, as
 well as missing support for many languages (and this is not a problem
 at all when using popular desktop software).  Fixig all cases is
 probably significant work, i.e. suitable for a hackathon, if core
 decides it's a good decision, and this PR is only nitpicking at one
 particular example while not solving much.

 As for obtaining the uptime in a sane manner for scripts if they'd want
 to avoid parsing inconsistent strings, a sysctl returning uptime in
 seconds might also be a better solution than adding a format option to
 uptime(1) (on this 5.0RC2 box I see no such uptime but there is
 boottime, expressed as a POSIX-locale timestamp, which is probably
 consistent enough for scripts too).

 Thanks,
 -- 
 Matt

From: David Holland <dholland-bugs@netbsd.org>
To: Matthew Mondor <mm_lists@pulsar-zone.net>
Cc: gnats-bugs@NetBSD.org, dholland-bugs@NetBSD.org
Subject: Re: bin/40337: Proposed localized change to w(1)/uptime(1)
Date: Sun, 15 Feb 2009 08:06:56 +0000

 On Sun, Feb 15, 2009 at 12:11:12AM -0500, Matthew Mondor wrote:
  > >  Unfortunately, strftime does not define a "short time" format that
  > >  would naturally produce %l:%M%p in the default locale. Probably it
  > >  should, but we don't really get to decide that.
  > >  Maybe a suitable hack would be to teach w which locales want %k:%M
  > >  instead of %l:%M%p? Is there any other alternative formatting that
  > >  anyone might (reasonably) want?
  > 
  > %X wouldn't be suitable for that "short time"?

 Well, in the default locale it prints "21:30:00" instead of " 9:30PM",
 and "09:30:00" instead of " 9:30AM".

 Obviously we could change that, but there are probably many uses of %X
 where it would be undesirable to drop the seconds, use a leading
 space, and/or use 12-hour time.

 There's %r, but it doesn't drop the seconds or the leading zero, and
 it's also not clear that it switches to 24-hour time in locales that
 don't like 12-hour time, which would defeat the purpose.

 The other issue I guess is readability; I find the current form quite
 a bit more readable at a glance than "09:30:00", the leading zero I
 think being the primary offender. This maybe doesn't matter that much,
 but it's the kind of thing that causes people to become vocally
 annoyed by (what they see as) a gratuitous change, and start messy
 flamewars on the lists.

  > I just checked what might be ideal for scripts but I'm surprised
  > uptime(1) doesn't allow date(1)-like format argument using strftime(3),
  > an argument to chose between 24h/12h time nor an argument to return the
  > uptime expressed in seconds.  Assuming these would exist, scripts would
  > no longer need to parse locale-specific output...

 There's an old PR I just found for an option to choose 24-hour time,
 in which it's noted that the login times of users in w(1) should be
 printed in 24-hour time too, which seems a valid point. That makes it
 more complicated, because that field doesn't have much space in it and
 making it wider isn't desirable.

 (What should the "Thu10AM" form become in 24-hour time, anyway?
 "Thu10" isn't any good. "Thu10:25" doesn't fit. Maybe "Thu1025"?)

 Hrm. I am probably thinking about this too much, but it's important to
 do things right...

  > I checked on a Debian system and uptime appears to return the C/POSIX
  > LC_TIME format with any locale set:
  > 23:33:03 up 2 days,  3:18,  3 users,  load average: 0.14, 0.05, 0.01

 That doesn't seem like the right answer.

  > I couldn't check the output on OpenBSD and FreeBSD.

 FreeBSD's appears to be the same as ours.

  > It should be noted
  > that the proposed change affects the returned current time and not the
  > actual uptime output, for which scripts may already use date(1)...

 That's probably true.

  > Some might still argue that under some locales a comma should be used
  > instead of a dot (i.e. LC_NUMERIC=fr_CA) for load averages, but this
  > change wouldn't address this.

 Since it's printed with %.2f this should happen automatically when/if
 we get the appropriate LC_NUMERIC support, which I don't think we
 currently have.

  > I actually have no strong opinion about this however, I filed the PR
  > after noticing a complaint from a user on IRC.  If it makes better
  > sense not to localize uptime or w output let's leave them as-is, of
  > course.

 I think it does make sense, one just has to be cautious. E.g. a
 certain tinted head-covering entity gratuitously changed the format of
 ls -l output; that made a nice mess. One of the selling points of
 NetBSD is and has been that we don't do stuff like that.

  > Admitedly, there are many non-localized cases in the base system, as
  > well as missing support for many languages (and this is not a problem
  > at all when using popular desktop software).  Fixig all cases is
  > probably significant work, i.e. suitable for a hackathon, if core
  > decides it's a good decision, and this PR is only nitpicking at one
  > particular example while not solving much.

 Fixing all cases is a huge timesink, and every case has the potential
 to break things or aggravate large numbers of people.

 I don't think it's unreasonable to want to be able to set LANG and
 still have shell scripts work. But as locales and locale support are
 defined for Unix, that's pretty much not possible. The first step
 towards sorting these issues out for real is going to have to be
 figuring out how to do it less invasively. This is both hard and
 an uphill battle against lame standards.

  > As for obtaining the uptime in a sane manner for scripts if they'd want
  > to avoid parsing inconsistent strings, a sysctl returning uptime in
  > seconds might also be a better solution than adding a format option to
  > uptime(1) (on this 5.0RC2 box I see no such uptime but there is
  > boottime, expressed as a POSIX-locale timestamp, which is probably
  > consistent enough for scripts too).

 awk < /kern/boottime '{ print systime()-$1 }'

 However, that doesn't help with user idle times in w, which are
 in fact probably the most likely scripting target of anything in this
 whole mess.

 So.

 I think there should be three modes, one that prints in 12-hour time,
 one that prints in 24-hour time, and one that prints everything in raw
 seconds. These modes should all be explicitly selectable via
 options. The default mode should be either 12-hour or 24-hour time
 based on the current locale.

 Does that make sense?

 -- 
 David A. Holland
 dholland@netbsd.org

From: Alan Barrett <apb@cequrux.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/40337: Proposed localized change to w(1)/uptime(1)
Date: Sun, 15 Feb 2009 15:45:27 +0200

 On Sat, 14 Feb 2009, David Holland wrote:
 >  Maybe a suitable hack would be to teach w which locales want %k:%M
 >  instead of %l:%M%p? Is there any other alternative formatting that
 >  anyone might (reasonably) want?

 If this is for time of day (as opposed to elapsed time), then I
 find %H:%M (e.g. "01:23") preferable to %k:%M (e.g. " 1:23").

 --apb (Alan Barrett)

From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: dholland-bugs@NetBSD.org
Subject: Re: bin/40337: Proposed localized change to w(1)/uptime(1)
Date: Sun, 15 Feb 2009 14:28:21 -0500

 On Sun, 15 Feb 2009 08:10:05 +0000 (UTC)
 David Holland <dholland-bugs@netbsd.org> wrote:

 >   > %X wouldn't be suitable for that "short time"?
 >  
 >  Well, in the default locale it prints "21:30:00" instead of " 9:30PM",
 >  and "09:30:00" instead of " 9:30AM".

 I now realized the issue involved for idle time columns, and indeed a
 special time representation would be needed for those if they were
 localized.  For timestamps which don't have to be restricted in length,
 interestingly I tend to prefer the leading zero versions :)

 >  There's an old PR I just found for an option to choose 24-hour time,
 >  in which it's noted that the login times of users in w(1) should be
 >  printed in 24-hour time too, which seems a valid point. That makes it
 >  more complicated, because that field doesn't have much space in it and
 >  making it wider isn't desirable.
 >  
 >  (What should the "Thu10AM" form become in 24-hour time, anyway?
 >  "Thu10" isn't any good. "Thu10:25" doesn't fit. Maybe "Thu1025"?)

 Thu1025 apprears reasonable

 >  Hrm. I am probably thinking about this too much, but it's important to
 >  do things right...

 This easily becomes a mess indeed.  For LOGIN I see i.e. 06Jan09 (which
 easily could have been 010609 but the former is much easier to read so
 is worth keeping, yet as we know some locales would expect 09Jan06
 etc), then Wed07PM indeed for a less-than-one-week time), which either
 could be expressed as a date like above instead, or as Wed0725,
 We7h25m, We07h25 or We07:25...  yet we have a problem since %a maps to
 three-character day representations, and I see no shorter
 representation, likewise with h and m abbreviations :)

 As for idle time, time seems expressed as number of minutes, hh:mm or
 <n>days where days apprears to be able to grow as necessary and column
 expanded?  If the column is expanded, the current model is fine and
 "days" would simply map to the locale's LANG if it was eventually
 localized.  If we wanted d for days, we have the same problem where a
 localized abbreviation is not even available (not that we couldn't
 trunk the strings, but hey).

 >  Since it's printed with %.2f this should happen automatically when/if
 >  we get the appropriate LC_NUMERIC support, which I don't think we
 >  currently have.

 Ah, right.

 >  I don't think it's unreasonable to want to be able to set LANG and
 >  still have shell scripts work. But as locales and locale support are
 >  defined for Unix, that's pretty much not possible. The first step
 >  towards sorting these issues out for real is going to have to be
 >  figuring out how to do it less invasively. This is both hard and
 >  an uphill battle against lame standards.

 Indeed, I now realize the mess involved.

 >  awk < /kern/boottime '{ print systime()-$1 }'
 >  
 >  However, that doesn't help with user idle times in w, which are
 >  in fact probably the most likely scripting target of anything in this
 >  whole mess.

 Hmm true, and which script writers probably already find a headache to
 parse since they cannot simply obtain it in seconds or minutes
 consistently (they have to account for every case w accounts for like
 <24h, >36h etc, but an option to w could provide a seconds, minutes or
 days only representation easily).

 >  I think there should be three modes, one that prints in 12-hour time,
 >  one that prints in 24-hour time, and one that prints everything in raw
 >  seconds. These modes should all be explicitly selectable via
 >  options. The default mode should be either 12-hour or 24-hour time
 >  based on the current locale.
 >  
 >  Does that make sense?

 It makes a lot of sense, and the raw seconds option would greatly help
 scripts.  How about the current time reported?
 1:25PM vs 13:25, 1:25AM vs 1:25, without padding 0?

 And remains to find which switchs to chose for the raw-seconds
 representation of uptime and idle time, and for the 12/24
 representations...  As for 12/24 mode the proper way to query it would
 be via nl_langinfo(3)?
 -- 
 Matt

Home	PR Database Search