Thinking About Progressive Timestamp Input Fields

While using a system that required me to enter a full timestamp, complete with milliseconds, reminded me of a timestamp variant I added to a project.

This was a text field that allowed the user to enter progressively longer timestamps that deviated from the current time. For example, a user could enter a timestamp like 12:20, which would be interpreted as 12:20 of the current day (I can’t remember the timezone but I think it was UTC). When prefixed with a single integer separated with a space, as in 5 12:20, it would interpret it as 12:20 of the 5th day of the current month. The month could be specified by prepending an integer followed by a dash, e.g. 3-5 12:20 would be interpreted as 12:20 of the 5th of March. Also possible were entering just the day, as in 3-5, which would be interpreted as the current time of that particular day.

I can’t remember how robust the whole thing was but I wouldn’t say it was an approach that’s applicable in all use-cases. It was for a system for searching over a few months worth of data at best, dealing with timestamps with second-level resolution. Making it approachable to users was also a challenge. I settled on adding a tooltip explaining the whole format when the user moused over the text field, which I agree is not a great solution, but was easy enough to code up.

Thinking about it now, it would be nice if more timestamp fields supported something like this. But then, I need to be really invested in the system I’m using in order to care. And I think this is where such a feature could potentially be less useful that I imagined. It’s easy enough for me to add it, especially when I had fun working on the project. But if it’s a piece of software that users endure more than enjoy, I don’t think they would notice it (unless things go wrong). For all I know, the system I’m using right now has a super whizzbang mini-language for entering timestamps that I could only dream about, if only I cared to look it up.