BrowserStack API returns UTC timestamps but UI shows local time – unresolved timezone consistency

Answer to the key questions

1. Should timezone be honored for on‑demand tests? No. The timezone payload field is documented to affect only scheduled (future‑run) sessions. On‑demand tests start immediately, so there is no scheduled start time for the API to adjust. Therefore the field is ignored for those tests.

2. Will BrowserStack introduce a global time‑zone setting? Currently there is no such option. The API always returns UTC, and the UI always converts to the viewer’s local zone. Any future global setting would need to be announced in release notes; until then, you must handle conversion yourself.

3. How can developers reliably convert UTC timestamps? Perform the conversion in your own code using a reliable time‑zone library (e.g., java.time.ZonedDateTime, moment-timezone, date-fns-tz, etc.). Store or present the converted value in the zone that matches your reporting or user‑experience requirements.

Confirmed facts

• The Automate API always returns start_time and end_time in UTC, regardless of test type.
• The BrowserStack UI automatically converts those UTC values to the viewer’s browser time zone.
• The timezone field in the API payload only applies to scheduled tests; it is ignored for on‑demand sessions.
• No global time‑zone configuration exists that would change API responses or UI conversion logic.

Practical conversion workflow

1. Call the Automate API for the session and capture the start_time (ISO‑8601 UTC).
2. Parse the string as UTC. In Java you could use:

   Instant utc = Instant.parse(startTimeStr);

3. Convert to the desired zone:

   ZonedDateTime local = utc.atZone(ZoneId.of("America/New_York"));

4. Format the result for display, e.g., local.format(DateTimeFormatter.ofPattern("yyyy‑MM‑dd HH:mm:ss z")).
5. If you need a single, consistent zone across all users, perform this conversion on the server side before persisting or returning data.

What we need to know

Do you need to aggregate session times across multiple users or accounts in a single, fixed time zone (for reporting or dashboards) rather than relying on each viewer’s local time? Knowing this will determine whether you should implement a global conversion layer in your application.