redpanda-data
Support raw values (epoch-millis) when searching by timestamp in Message viewer
The ability to find messages/offsets by timestamp is very handy when trying to locate specific messages in the Message view (available with #99).
However, it seems that this is currently only possible via the timepicker. If the time you're looking for happens to be a raw (unix millis) timestamp, the timepicker is extremely uncomfortable and error-prone to use. It also doesn't support a finer granularity than seconds as far as I can see - which can be an added problem for partitions that are heavily written to.
Would it be feasible to also permit pasting a raw millis-timestamp into the search field?
Hey @s-rwe , yes totally makes sense. From a UI/UX perspective a little bit more challenging to keep the UI sleek and intuitive with an additional option or a more complex time-picker, but your point is of course totally valid 👍
@weeco - I totally understand that it might not be trivial to combine the timepicker with a raw timestamp directly in the UI. And if it's done as a separate option, it doesn't seem too nice from a UX point of view either...
Then again, from a developer perspective it is quite a common usecase, so it would be great to have it available via some way :)
Proposal:
(edited Dec 14 with the one we've decided on)
The "Timestamp" selection turns into a box, instead of opening up the calendar automatically. In that text box, users can type/paste their timestamp, OR they can open the calendar by clicking the icon.
https://github.com/redpanda-data/console/assets/129790723/717fedaf-6db7-4298-b876-1f4419f60d2f
@ivpanda I like the proposal, but one thing to consider is about whether to provide this timestamp input in ms without some kind of submit option. Data in this case is updated in the portal on change, and if you have sth like 1708433852927 and you'd want to change this you'd trigger multiple requests while doing so. It's ok when user does copy&paste, it's a bit worse when you try to modify this inline.
[...] It's ok when user does copy&paste, it's a bit worse when you try to modify this inline.
FWIW, this is an effect I have also struggled with already, in the related option to search for a Custom offset. For example, if I look at the messages of a partition for some starting offset (say, 2317509066) and then I want to jump a certain amount of messages back from here (say, 150), it becomes fairly painful to do this inline exactly because of the live-updating on each character. For me, I typically end up editing the offset in an external editor and pasting the result back in instead (works, but inconvenient).
And on another note, the text-field shown for a Custom offset is layed out too small which doesn't help either for such manual editing (offsets of 1B or more are cut off in the view, at least for me under Chrome - I see at most 9 characters in the box).
Anyway, this is all bit unrelated but still touches on the same concern. In case you consider having some sort of explicit 'submit' option for the timestamp box, it would be good to have the same also for the Custom offset - both for consistency and convenience :)
Wondering if it's an option to have the timestamp input/display field as part of the datepicker panel that pops up as soon as you click the calendar icon? I assume we could make it more obvious to ask and/or show the unix timestamp. What do you think @ivpanda and @jvorcak ?
@jvorcak and I discussed this:
I'd rather not add the timestamp input into the calendar popup because semantically it doesn't make sense, and it takes away the speed of it. He'll investigate letting the user send this by hitting Enter or clicking elsewhere.
Hi @ivpanda, I've investigated this one after some time today.
What is in-theory possible is to show unix timestamp as a value and only change it on Enter and clicking elsewhere. It'll take some time to implement this so I want to double check that I should dive into it.
One thing that I've found out is that some users are used to provide values in seconds, some in milli-seconds. We'd need to choose one of them and somehow let them know (e.g. by using the placeholder).
So to sum up:
- The solution we talked about is in-theory possible, but it will take some time to implement
- I'd still be happier if we could solve this UX-case differently, but I don't know how :/
- Sorry I couldn't deploy any demo, but it's hard to provide for now, and it'd take some time to cover all corner cases, but now we know it should be realistic to deploy what we talked about last time.