Hi @coreteam I found many time info in redis is unix timestamp . Maybe we can add some human readable format like memory human? The following are the cases that can be thought of... - [ ] lastsave human - [ ] info: rdb_last_save_time
Does it be worth doing ? If yes... I would like to statistics timestamp usage status and extend some human format
Comment From: oranagra
i think the LASTSAVE command is probably a relic of before INFO was created, don't want to extend it. It may be useful to extend some of the INFO timestamps to be more human (redis-cli / shell) friendly, but we probably don't want to show a formatted date, but rather age like, either always in seconds, or converted to minutes / hours / days if it's very high..
Comment From: OhBonsai
I think there's two kinds of time could be more readable.
One is unix timestamp like rdb_last_save_time. we can format it in two ways
1. use time format in log like11:M 09 Aug 2021 11:28:28.207
2. use meoment from now. like 2 days ago which is defined in moment.js
Personally i would prefer option1. So i can know time clearly. But maybe option2 is more elegant
The other is time duration like uptime_in_seconds or uptime_in_days. There is also two options
1. vanishing time duration. eg. 3700sec just show 1h
2. precise time duration. eg. 3700sec => 1h1m40s
I like option2.
@oranagra , what's your opinion
Comment From: zuiderkwast
use time format in log like
11:M 09 Aug 2021 11:28:28.207
Since dates are written in different order in different countries (even UK and US use a different order of day and month), I'd prefer if we use ISO 8601 for the human format, e.g. 2021-08-09T11:28:28.207Z.
Changing from Unix timestamp to another format may not be backwards compatible though. Clients and tools could do this formatting instead.
Comment From: oranagra
i think that like used_memory, we wanna show two forms, one is meant to be processed by software (so the unix time is good for that), and the other is meant to be easily consumed by a user watching a terminal, for that one i think we can use a notation like 1h2m30s.
so something like
rdb_last_save_time:1628514560
rdb_last_save_age:1h2m30s
if we wanna add these approaches for uptime, we can add
startup_time:1628514560
startup_age:1h2m30s
but the latter is already covered by uptime_in_days, etc.
if for some reason someone wants to convert these back to absolute time, programatically, he can use server_time_usec.
we obviously can't change existing fields due to backward compatibility concerns.