Date and Time Formats

Reference for all date and time formats used in Argon JQL functions.

Date Format

Used in: changedBy, transitionedBy, commented, attachment, worklog, lastCommentedBy

Accepted formats

Format	Example	Notes
yyyy/MM/dd	2024/01/15	Date-only (slash). Resolves to start- or end-of-day in UTC depending on whether it's a start_date or end_date — see Boundary rule.
yyyy/MM/dd HH:mm	2024/01/15 14:30	Date + time in UTC.
yyyy/MM/dd HH:mm <timezone>	2024/01/15 14:30 Europe/Warsaw, 2024/01/15 14:30 GMT+2	Date + time in the specified timezone. Both IANA zone names and GMT±HH[:MM] shorthands are accepted.
yyyy-MM-dd	2024-01-15	ISO-8601 date-only. Resolves per the Boundary rule.
yyyy-MM-ddTHH:mm[:ss[.SSS]]	2024-01-15T14:30, 2024-01-15T14:30:00.123	ISO-8601 date-time. No offset → interpreted as UTC.
yyyy-MM-ddTHH:mm[:ss[.SSS]]Z	2024-01-15T14:30:00Z	ISO-8601 in UTC (explicit Z).
yyyy-MM-ddTHH:mm[:ss[.SSS]]±HH:MM	2024-01-15T14:30:00+02:00, 2024-01-15T09:30:00-05:00	ISO-8601 with explicit offset.

Boundary rule

When you pass a date-only value (no time component), Argon needs to pick a moment within that day. The choice depends on which argument the date is for:

• start_date → resolves to the start of the day (00:00:00.000).
• end_date → resolves to the end of the day (23:59:59.999), inclusive.

If your input includes an explicit time (HH:mm or ISO T…), this rule does not apply — the time you typed wins, and end_date is treated as an exact instant, not the end of the day.

-- Both ranges below cover the entire day of 2024/01/15 in UTC:
issue in changedBy("project = DEV", "Status", "2024/01/15", "2024/01/15")
issue in changedBy("project = DEV", "Status", "2024-01-15",  "2024-01-15")

-- Explicit time → exact instants, not whole-day windows:
issue in changedBy("project = DEV", "Status", "2024-01-15T09:00:00Z", "2024-01-15T17:00:00Z")

Timezone rule

• Date-times without an explicit timezone are interpreted as UTC.
• To pin a specific zone:
  • Append an ISO offset: +02:00, -05:00, Z.
  • Or use the slash format with a trailing zone: Europe/Warsaw, GMT+2.
• The start_date / end_date boundary expansion happens in the inferred zone, so 2024/01/15 Europe/Warsaw as an end-date resolves to 23:59:59.999 Warsaw time (21:59:59.999 UTC in summer, 22:59:59.999 UTC in winter).

Examples

-- Date-only, both bounds inclusive over the day
issue in changedBy("project = DEV", "Status", "2024/01/01", "2024/12/31")

-- ISO with explicit timezone offset
issue in transitionedBy("project = DEV", "Done",
                        "2024-01-15T09:00:00+02:00",
                        "2024-01-15T17:00:00+02:00")

-- Slash format with IANA timezone
issue in transitionedBy("project = DEV", "Done",
                        "2024/01/15 09:00 Europe/Warsaw",
                        "2024/01/15 17:00 Europe/Warsaw")

Querying "today" in your timezone

If you're in EST (UTC-5) and want issues changed on Jan 15 local time, you can pin the zone directly instead of computing the UTC offset yourself:

-- ISO with offset
issue in changedBy("project = DEV", "",
                   "2024-01-15T00:00:00-05:00",
                   "2024-01-15T23:59:59-05:00")

Relative dates

In addition to absolute dates, start_date and end_date accept a relative expression: a leading - followed by a duration (units w/d/h/m/s, see Time Expression Format). It resolves to now minus that duration, evaluated each time the query runs.

Input	Meaning
-2w	2 weeks ago from now
-3d	3 days ago from now
-1w 3d	1 week and 3 days ago from now
-12h	12 hours ago from now

Because the value is re-resolved on every evaluation, relative dates power self-updating dashboards — e.g. "issues changed in the last 2 weeks" never needs editing. Argon refreshes such queries hourly so the window stays current.

-- Issues changed by a user in the last 2 weeks (rolling window)
issue in changedBy("project = DEV", "", "-2w")

-- Comments added in the last 3 days
issue in commented("project = DEV", "", "-3d")

The relative form is a precise instant, so the Boundary rule (start/end-of-day expansion) does not apply to it. Only a leading - (past) is supported.

Time Expression Format

Used in: timeInStatus, timeExpression, worklog (min/max time spent)

Units

Unit	Meaning	Example
w	Weeks	2w = 2 weeks
d	Days	5d = 5 days
h	Hours	8h = 8 hours
m	Minutes	30m = 30 minutes
s	Seconds	45s = 45 seconds

Combining Units

You can combine multiple units in a single expression:

2w 3d 4h 30m

This equals: 2 weeks + 3 days + 4 hours + 30 minutes

Examples

-- Find issues in progress for over 2 weeks
issue > timeInStatus("project = DEV", "In Progress", "2w")

-- Find issues in review for less than 3 days
issue < timeInStatus("project = DEV", "In Review", "3d")

-- Find issues with 2+ hours of worklogs
issue in worklog("project = DEV", "", "", "", "2h")

-- Use with Time in Status custom field
"In Progress.time" >= timeExpression("1w 2d")

-- Complex time expression
issue > timeInStatus("project = DEV", "Blocked", "1w 3d 4h")

Conversion Reference

Expression	Equivalent
1w	7 days
1d	24 hours
1h	60 minutes
1m	60 seconds

Notes

• Order doesn't matter: 2d 1w equals 1w 2d
• Spaces are optional: 2w3d equals 2w 3d
• Values can be any positive integer
• No decimal values: use 1h 30m not 1.5h

Function Reference

Functions Using Date Format

Function	Parameters
changedBy	start_date, end_date
transitionedBy	start_date, end_date
commented	start_date, end_date
attachment	start_date, end_date
worklog	start_date, end_date
lastCommentedBy	start_date, end_date

Functions Using Time Expression

Function	Parameters
timeInStatus	time_expression
timeExpression	expression
worklog	min_time_spent, max_time_spent

Error Messages

Invalid Date Format

Invalid date format. Expected: yyyy/MM/dd[ HH:mm[ tz]] or ISO-8601 (e.g. 2024-01-15T10:00:00Z) or a relative expression like -2w

Check your date string against one of the accepted formats.

Invalid Time Expression

Invalid time expression. Expected format: 1w 2d 3h 4m 5s

Check for typos in unit letters or invalid characters.