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

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

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

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