Re: Feature request for shorter relative date format in log
- From
Taylor Blau <me@ttaylorr.com>
- Date
- Aug 4, 2023, 18:24 UTC
- Message-ID
- <ZM1Ccn766xge31Uo@nand.local>
- In-Reply-To
- <xmqqsf915b54.fsf@gitster.g>
On Wed, Aug 02, 2023 at 03:31:51PM -0700, Junio C Hamano wrote:
Show 7 quoted lines
> Taylor Blau <me@ttaylorr.com> 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?
I'm not aware of such a utility, no. I had imagined that we would represent the duration between two timestamps as another timestamp offset that same amount after the Epoch. Then the caller could specify a strftime format string and format the "duration" that way.
Show 13 quoted lines
> 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.
Yeah, I think mangling with those translation identifiers is going to be a giant mess.
> No, I am not interested in working on such a solution myself. But > it will be an interesting puzzle.
Ditto ;-).
Thanks, Taylor