We’ve significantly improved Papertrail’s time and date seeking. Times and dates are more reliably recognized, times honor your Papertrail profile time zone, and more formats are supported.
What changed?
In the event viewer, you’ll see the same clock icon. As usual, clicking it will expand the time and date seek:
While the interface served its purpose well, the seeked-to location sometimes didn’t match expectations. Here’s what we did to eliminate those cases.
Better parsing
First, as of today, the time or date you enter is much more reliably recognized. This eliminates all known cases where dates or times were mis-interpreted. Nearly any understandable date or time format should work, like:
4:06 pm
yesterday at 5:30pm
3 hours ago
2013-08-20 04:12:55
5 AM Friday
Profile time zone
Second, the time is now interpreted according to the time zone set in your Papertrail user profile. Previously, Papertrail used the time zone of the computer you are browsing from. More below on how this came together.
More formats
Finally, additional time and date formats are supported. When copying and pasting from a terminal window or customer support email, almost any existing time representation should now be recognized. When you know when something happened, start there.
Under the hood
Implementing this elegantly was more challenging than we expected. To us, “elegant” meant:
- honoring the Papertrail time zone setting, since log timestamps are displayed in the profile zone. Seeking to 9 AM (according to the workstation time zone) and arriving at messages saying 5 PM (in the profile zone) wasn’t intuitive at all.
- displaying the time instantly as I type each character. We tested server-based parsing too, but even when implemented as a standalone Web service, it doesn’t feel as responsive.
- supporting relative times. I want to type what’s on my mind, even when it’s as simple as
20 minutes ago. - recognizing multiple time formats, so that I don’t need to check the docs and reformat my timestamp
- treating input as past times (as Papertrail already did), so
3 PMmeans “the most recent 3 PM to have already occurred” rather than “today at 3 PM”
Most other time and date interfaces we’ve seen omit at least one, and often two or three, of these conveniences. After implementing them for Papertrail, we understand why.
Biasing times towards the past was particularly challenging, since 3 AM yesterday in another time zone may be a completely different day. The time zone adjustment must occur prior to interpreting the time. The intersection of these 5 features leads to Sugar.js. We appreciate the help of its primary author, Andrew Plummer.
How is it?
Our aim was to make time seeking predictable, responsive, and complete – in a word, elegant. If you experience anything else, we want to know. Enjoy!