nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JIRA API: JQL datetime format does not have timezone.

Phil_Dimeski

Hey there,

I am making an API requests to JIRA requesting all issue update since a certain time. What I have noticed is that the format for the datetime fields in JQL are yyyy-MM-dd HH:MM, which does not include any timezone specifications. It would be nice to be able to specify the timezone in a JQL query so that the correct data is returned. Especially when other datetime fields in the API include it.

Cheers, Phil

Accepted answers

Daniel Eads

Hi Phil,

My assumption is that unauthenticated requests will run using the server time - you can fetch this from /rest/api/2/serverInfo at the end of the serverTime property. Authenticated requests should run using the timezone set by the authorized users, also fetchable via /rest/api/2/myself in the timeZone field. The myself endpoint will return a 404 if the API call is unauthenticated. Hopefully this provides you a way to work around the current lack of timezone support in JQL (with a few extra methods for timezone verification unfortunately).

It looks like there was a previous feature request to get timezone support added to JQL, but was closed due to lack of interest: JRACLOUD-17359. Definitely disappointing, but it looks like it is possible to get the right results with a little extra API work to double-check what timezone the JQL is being processed as (either Server default time or the user's specified timezone).

Cheers,
Daniel

All comments

Daniel Eads

Hi Phil,

Cheers,
Daniel

Phil_Dimeski

Cheers, Daniel this is what I am currently doin, just thought I would double check.

Robert Metzger

According to this JavaDoc, the serverTime is "null" when the user is unauthenticated:

current time (when the response is generated) on the server side or null when the user is not authenticated.

I have not found a way to get the server's time.

Daniel Eads

Hey Robert,

You are correct - I've just tested against 7.13.1 and there is no serverTime property returned when the endpoint is accessed without a user session. You'll need to use an authenticated user session or pass basic auth when you hit the endpoint to retrieve the server time.

Note that you can still retrieve issues from a JQL search while unauthenticated (if the issues are public). The times returned for these issues will be in the server's configured timezone. But as you have pointed out, you cannot get that timezone while anonymous.

William Tyler

The ability to specify known times is an important one. I'm working on a team within the change management initiative. We need to run a series of queries to gather tickets that have specific time fields, and without jumping through hoops, it's very difficult to be sure that we're getting the actual time interval we want. For instance, we might want to get all the relevant tickets created between 2020-01-01T00:00:00Z and 2020-01-14T24:00:00Z. There's no easy way to do this in code without first finding the difference between the time Jira "thinks" we're located in and UTC. And, to make matters worse, if we try to do this somewhere near daylight savings time transitions, we may miss a significant part of the interval. It would be a huge help if JQL could accept date-time in full ISO format, including the timezone specifier.

Ben Ernest-Jones

We just ran into the same issue... we base our release notes on an automated process that looks for all tickets closed between the start date of a sprint and the end date of a sprint, but also manually reviewed beforehand.

This release we had a ticket that was closed just after midnight of the last day, but midnight my timezone, so I didn't see it in my manual review of the tickets. The build server that generates the release notes runs with a user in a different timezone that did include that ticket, so it went out unreviewed.

It would be more consistent, clear and safer if we could definitively say "all tickets between this time and this UTC".

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

api

jira-cloud

jql

date-time

timezone