FR: standardize jj log output timezone

[rdamazio]

Is your feature request related to a problem? Please describe. I just updated my clone of the jj upstream code, and was struck by the fact that my working directory is on top of a change in the "future" (because it came from Japan) - clearly, this is a bit confusing (and probably even more so when the timezone difference is smaller).

Describe the solution you'd like In order to make times more easily comparable, it'd probably make sense to always output in the local timezone unless the user explicit asks it to do otherwise?

Describe alternatives you've considered Always outputting in an arbitrary time zone (UTC?) would also make them comparable, but still harder to make sense of vs "now".

Additional context

@  pwrrtvzoxqop [email protected] 2024-01-30 20:47:45.000 -08:00 44b5a0c20f9f
│  (empty) (no description set)
◉  yyqlyqtqwvrz [email protected] 2024-01-31 09:40:52.000 +09:00 main 976b80120885
│  index: on reinit(), delete all segment files to save disk space
~

(also, what's with the fractional seconds? Are those ever relevant?)

[ilyagr]

This is now pretty well configurable, but it seems we haven't updated the default to something more sensible.

One possible default is to use relative timestamps by default.

template-alisases."format_timestamp(timestamp)" = "timestamp.ago()"

For absolute timestamps, I don't mind timezones. They remind me of where people are, and it usually shows both my and their timezone offset, so that I can tell how many hours ahead/behind they are. I agree that we shouldn't show the always-zero microseconds by default, and I'd skip the seconds as well.

This is implemented, but only documented in the template alias docs at the moment, and there is no nice preset. I like the following:

template-aliases."format_timestamp(timestamp)" = "timestamp.format(\"%Y-%m-%d %H:%M %:::z\")"
# Example: 2023-04-04 18:38 -07
# This might be imperfect if somebody is in a fractional timezone (+5h30min). 

We could create a default alias template-aliases.sensible_absolute_timestamp() with something like that. Then, even if the relative timestamp is the default, people could easily switch it to a reasonable-looking absolute timestamp.

BTW, timestamps can already be converted to UTC, see the template alias docs. There's currently no way to convert a timestamp to the local time zone, but that shouldn't be hard to add.

[yuja]

Perhaps, the fraction part can be hidden by default. It's always zero in Git backend, and it wouldn't be important in op log either.

FWIW, I prefer the current ISO 8601 format because relative timestamp isn't easy to parse.

[joyously]

Are the timestamps not normalized at all? Does this affect sorting by date?

I prefer actual dates, (that don't change), so the relative ago() is not a good default for me, although if both are shown, that would be fine. But seeing a future date in the history doesn't make much sense.

[yuja]

Are the timestamps not normalized at all? Does this affect sorting by date?

Sorting isn't affected. The underlying data is (utc_msec, tz_offset) pair.

[martinvonz]

I agree with @rdamazio that my local timezone is generally more useful. What do others think? What should the default be?

[yuja]

I prefer to see the raw metadata, but I don't mind if it's translated to local timezone. I don't like .ago().

[mhammond]

I agree that my local timezone is generally more useful. .ago() etc work fine in a rich UI as you can generally (eg) hover to get the actual time, but when there's no way to have both I'd strongly prefer my local time.

[mhammond]

I just re-read the context and want to change my answer :)

This is now pretty well configurable. One possible default is to use relative timestamps by default.

This is just for the default output and can be overridden, right? Maybe we can have both? If we care about the timezone, it's a very recent change, and probably want a more exact output. A little older we don't care about the time, just the date. A little older again and .ago() would be perfect.

[ilyagr]

I like the timezones, but it doesn't matter much to me. I think it'd be fine to make the default be the local timezone. I think this mainly requires adding one simple function to the timestamp type in the templating language.

This is just for the default output and can be overridden, right? Maybe we can have both? If we care about the timezone, it's a very recent change, and probably want a more exact output

Currently, the templating language is not powerful enough for this, but I think that conceptually it would cover it. We'd need to define a duration type, subtraction of dates, and comparison of durations.

If we went in this direction, my preference would be the opposite, though: I'd want .ago() for recent changes (up to a day? a week?) and exact dates for more distant changes.

[joyously]

I am not in favor of the output changing over time. It should be consistent, for ease of reading and parsing. That's why I don't like relative times. They are only valid very briefly and you can't see the real time to use it.

[ilyagr]

That makes sense. Judging by the thread, quite a few people don't like the idea of relative times being the default, so I was already ready to conclude that we're probably not doing that. Thanks to your comment, I now have a better idea of why people feel this way.