Burp Suite User Forum

Create new post

Burp Enterprise date/time format

Kamil | Last updated: May 26, 2021 06:24PM UTC

After working with the Enterprise trial version for a short period, I'm baffled how a company with such experience with web application (security) details, can have so many (usability) details done so bad. I'll start with a simple one, which is mostly annoying and it's probably my OCD kicking in, that I'm starting with it. Burp Enterprise has no way to specify the date/time format I would like to see in the application, nor the time zone I would like it to use, when showing me dates and times. This is bad. What is worse, that although the application does not have so many pages, the application uses the date/time format so inconsistently, that I have counted at least 4 different formats. Those may somehow depend on my environment (browser or server) setup, so I'm not sure if you'll see the same in the same places. - scan list page shows e.g. "2021-05-26 1:37 PM" so ISO-like (ISO8601/RFC3339) date and am/pm time and no time zone - specific scan page shows e.g. "Today at 1:37 PM", so relative date and am/pm time and no time zone - some found issues, e.g. TLS certificate details show e.g. "Wed Oct 07 19:21:40 GMT 2020", so some kind of ANSI C (or obsolete HTTP) format (with GMT time zone), - event log export (so CSV format) shows e.g. "May 17 2021 at 20:37:57", so American-style date and 24-hour time, - licensing (trial expiration date) shows e.g. "June 4, 2021 (8 days left)", so a different American-style date and a relative date, without time and time zone. Scan reports will use a mix of those (I've seen at list first and third of those used). None of the formats is machine-friendly, including the one for machine use (the CSV file, which is hardly human-readable too). I absolutely hate all of them. For those without time zone, I have to guess, if it's using mine, server's or UTC maybe. For the relative ones, I have no simple way of checking, if it's understanding of "today" matches my today (or even if it uses the same "now"). And I hate American-style date format and the am/pm time. I would suggest to: 1. Introduce user preferences, allowing indication of preferred date and time format and user's time zone (with option to auto-detect, so traveling people don't have to switch it, but they still should have a way to see which time zone was auto-guessed). 1.a. If it's too much (i.e. offering it to each user separately), allow at least application-wide way of providing those configuration values, available to admins. 2. Show the current date, time and time zone somewhere in the UI, using the format and time zone from the preferences, so you know what the server considers as "now" in a clear and readable form. 3. Show all dates in the application UI consistently using the format and time zone from the preferences. 4. If a "short" time format is used anywhere for readability or space (e.g. without full date, like the relative format or without time zone, etc.), then provide a tool-tip, which will show the full value. The "short" time format should either be part of the format configuration or be based on it (so when I pick "YYYY-MM-DD" for date, I will not see "Mmm DD" for short date). 5. Either provide a separate setting for it or use machine-friendly format (e.g. ISO8601/RFC3339) for machine-use documents (e.g. CSV) or use document formats which have/require/enforce a specific way of representing date/time. 5. Either provide a separate setting for it (global or for each user or for each export) or at least have a consistent one for human-readable document exports (e.g. scan reports).

Michelle, PortSwigger Agent | Last updated: May 27, 2021 11:08AM UTC

Thanks for taking the time to provide such detailed feedback. We are aware of these issues and this is an area we plan to work on. I have passed on your feedback to the team so they have the details of what you would like to see. I have linked this thread so we can post back where when there are updates.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.