Re: Feature request for shorter relative date format in log

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Taylor Blau <me@xxxxxxxxxxxx> writes:

> But we don't have a way for users to provide custom over relative dates.

Are there existing systems to format time durations in a customized
way, just like strftime() is a way way to custom-format a timestamp,
that we can just use, or write our own modelling after them?

The relative-time code decides which points in the time durection
spectrum are good places to switch the granularity (e.g. up to 90
seconds we will give "N seconds", and up to 90 minutes we will give
"N minutes").  You could grep in date.c:show_date_relative() for
Q_() and _(), and place them in an array and allow them to be
replaced by strings in the configuration variable, but that will
cover only one smaller half of the problem (i.e. how the "N seconds"
are shown) and the other half (i.e. what variants there are, and
which variant is used for what time duration---you cannot introduce
a rule that says "up to 500 seconds, show 'N minutes M seconds'").

Even with that solution to the smaller half will also create i18n
headaches.

> Perhaps we should?

It will be an interesting puzzle, if done well.  Even though my
criteria to consider that a solution is done "well" is not that
high, it should at least allow defining your own variants.  Instead
of the rules that are implemented as hardcoded if-statement cascade
in date.c:show_date_relative(), it should allow you to say something
like

    * For a timestamp that is N seconds into the future, format a
      relative timestamp that is N seconds ago, and replace "ago"
      with "in the future".

    * For a timestamp that is less than 1200 seconds ago, show "N
      minutes M seconds ago" (with appropriate pluralization for
      "minute" and "second" when N and/or M is 1).

    * For a timestamp that is less than 5 hours ago, show "N hours M
      minutes ago" (ditto about plural).

and so on.

No, I am not interested in working on such a solution myself.  But
it will be an interesting puzzle.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux