Re: bin/40337: Proposed localized change to w(1)/uptime(1)

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR bin/40337; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, dholland-bugs%NetBSD.org@localhost
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@localhost