rfmoz
Table output alignment
Hi, I think it could be a simple justification, my output with tuptime -t looks like
locale with en_US:
tom@mycarbon:~$ tuptime -t
No. Startup T. Uptime Shutdown T. End Downtime
1 05:21:07 PM 06/21/2025 60d 22h 23m 6s 03:44:13 PM 08/21/2025 OK 14s
2 03:44:27 PM 08/21/2025 17d 5h 14m 36s 08:59:03 PM 09/07/2025 OK 11s
3 08:59:14 PM 09/07/2025 16d 17h 11m 42s 02:10:56 PM 09/24/2025 OK 10s
4 02:11:06 PM 09/24/2025 54d 0h 44m 26s
switching to en_DK.utf-8 locale , the same at the Uptime column:
tom@mycarbon:~$ tuptime -t
No. Startup T. Uptime Shutdown T. End Downtime
1 17:21:07 2025-06-21 60d 22h 23m 6s 15:44:13 2025-08-21 OK 14s
2 15:44:27 2025-08-21 17d 5h 14m 36s 20:59:03 2025-09-07 OK 11s
3 20:59:14 2025-09-07 16d 17h 11m 42s 14:10:56 2025-09-24 OK 10s
4 14:11:06 2025-09-24 54d 1h 18m 54s
Maybe someone can beautify it, wouldn't it better to first start with the day and then time at the Startup and Shutdown column eg.
1 2025-06-21 17:21:07 60d 22h 23m 6s 2025-08-21 15:44:13 OK 14s
that would be clearer and more convinient.
BR Thomas
Hi tkuschel,
As you've discovered, the datetime order is based on the locale definition. But it is possible to override it with -d / --date argument :
tuptime -t -d '%Y-%m-%d %H:%M:%S'
Please, take a look to all parameters that this option accept on the tuptime manual
Thanks,
Hi rfmoz, thx for the answer. I like your script!
I really know about the params -d '%x%X aso. But I wanted a more beautiful aligned output especially with param -t (table).
I already discovered my problem of not so nice aligned "humanized" uptime seconds and already wrote an additional time_conv (secs) function for it.
The output of the table is e.g. shown on a server at https://kuschel.at/tuptime2.php and tuptime -e 12 at https://kuschel.at/tuptime.php with the locals settings of LC_ALL=en_DK.utf-8 for testing.
I'm still working on it. I don't have much time at the moment, but I'll share it.
For now it has 2 more parameters and the function `humanize_seconds(sec, pad=True, show_zeros=True) does the following: (also seen at my fork of the tputime under tkuschel, branch 'tk_tuptime')
Maybe we could also adjust the new behaviour via the command line?
def humanize_seconds(sec, pad=True, show_zeros=True):
"""
Convert seconds to a human-readable duration string.
Parameters
----------
sec : int
Number of seconds.
pad : bool
If True, pad all units after the first with zeros.
show_zeros : bool
If True, show zero-values for smaller units; if False, omit them.
Returns
-------
str
Human-readable duration.
Examples
--------
>>> humanize_seconds(0)
'0s'
>>> humanize_seconds(5)
'5s'
>>> humanize_seconds(60)
'1m 00s'
>>> humanize_seconds(3600)
'1h 00m 00s'
>>> humanize_seconds(3661)
'1h 01m 01s'
>>> humanize_seconds(3600, pad=False)
'1h 0m 0s'
>>> humanize_seconds(3600, pad=False, show_zeros=False)
'1h'
>>> humanize_seconds(7322, pad=False)
'2h 2m 2s'
humanize_seconds(3601, pad=True, show_zeros=True) # '1h 00m 01s'
humanize_seconds(3601, pad=True, show_zeros=False) # '1h 01s'
humanize_seconds(3601, pad=False, show_zeros=True) # '1h 0m 1s'
humanize_seconds(3601, pad=False, show_zeros=False) # '1h 1s'
"""
Best regards Thomas
Hi tkuschel,
Great to know! thanks for the feedback. With the website content I've clearly got your idea about the order between date and hours. I haven't realised about that detail until now.
I don't really know why is the current order set, it was too back away. But it's true that your proposal seems more natural and widely expected. I'll change it.
About the padding on the time counter, it looks better on table output, definetively, but on default ouptut seems a bit odd, isn't it? maybe is my perception, but is that why you only change it for the table?
A quick look on humize_seconds() gives me the lack of years counter, a that reminds me about how many padding needs the days, for example:
1y 004d 16h 13m 02s
131d 06h 01m 22s
010d 12h 14m 01s
Do you have any idea about how to manage this? Some time counter doesn't use years, but I really like it.
I'll take a deep look to the way that you printed the table format, I like it because it seems cleneaner. In that way, the balance between new code lines and the relevance of the change must to be positive, I mean, an small cosmetic change only worth if it only involves a few code lines. Maybe refactoring current time_conv() could produce the padding output easily.
Anyway, the dev branch has a few fixes and upgrades, you could use it as source without problem.
Thanks,
Hi rfmoz,
Thanks Ricardo for your reply and your thoughts. I'll see if I can extend the current time_conv() with padding so that there are as few changes as possible in the program's output. What do you think about introducing a parameter, e.g., --legacy, so that the original formatting can remain the same?
With the new formatting, we could also incorporate --days-only, then extend this with the years 1y 012d 04h 13m 02s and, if --days-only is used, then 377d 04h 13m 02s.
Have you ever considered storing all settings, such as localization, in /etc/tuptime.conf or in the database itself?
I will try to revise “time_conv()” with parameters and remove my additional function.
In my developments, I only wanted to keep it for the table output. I think next week I'll have more time to implement that on dev branch. However, there's no need to rush.
BR Thomas
Hi tkuschel,
Don't worry, I've plans to try the padding output in a few weeks (hope!) to check how it looks. But I'll try to keep the current number of arguments, so it will turn into default output format if suceed.
Also, the use of configuration file exceeds the simplicity of the program, the idea of use de DB as conf store could be an alternative, but I think that it doesn't worth it. As example, it is possible to set the Tuptime DB path via env. varriable, that's the simplest workaround to the use of a conf file. Anyway, I appreciate your suggestion.
Thanks,