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; } } }

Solution for calculating business hours between two date / time stamps in Jira custom fields

Mark W. McColgan

I have a requirement to calculate business hours between two date/time stamps in custom jira fields or a custom field and 'now' which considers normal business hours and holiday calendar. Has anyone found and implemented a good solution ? For one of serveral examples, I want to know the exact business hours between issue creation and the current date/time.

Accepted answers

All comments

Trudy P Claspill

Hello @Mark W_ McColgan

Take a look at this answer provided by the inimitable @Bill Sheboy , one of the community's well-recognized SMEs when it comes to Automation Rules.

https://community.atlassian.com/forums/Jira-questions/Find-Business-hours-since-issue-creation-using-jira-automation/qaa-p/2618217#M924560

Germán Morales

Hi @Mark W_ McColgan, @Trudy Claspill already pointed you to @Bill Sheboy's classic answer, which is the right reference for an Automation only solution. Let me add the trade offs by approach so you can pick the one that matches your use case.

1. Native Automation, rough estimate. The closest built in primitive is {{issue.created.diff(now).businessDays}}, which counts Monday to Friday and treats 9am to 6pm as the working window (9 hours). For a "good enough" hours figure you can do:

{{#=}}{{issue.created.diff(now).businessDays.abs}} * 9{{/}}

This does not respect holidays and does not handle partial days on the boundaries (so an issue created at 5:30pm is counted as a full business day). It is fine for SLA dashboards where directional accuracy is enough, not for billing.

2. Native Automation, accurate. Bill's approach (calculate the partial hours on the start day, the partial hours on the end day, and the full business days in between) gives you correct business hours but you have to model holidays yourself, typically as a JSON list of dates that you check with a condition. It scales poorly past one rule.

3. JSM SLA, the cleanest native option for holidays. If the work item lives in a Jira Service Management project, SLA Goals natively support a Calendar with working hours and a holiday set defined in Project settings > Calendars. You then expose Time to resolution or a custom SLA, and read the elapsed business time directly. This is the only fully native path I know of that handles holidays properly. If your issues are in Jira Software only, this is not available.

4. Marketplace apps. For Jira Software, several apps compute time in status / lead time against a configurable working calendar with holidays (Time in Status, Timepiece, Status Time Reports, among others). I would not lead with this unless you have already tried 1 to 3 and the constraints do not fit.

References:

Automation smart values - date and time (see Date difference and Date plus unit)
What are SLAs in JSM (Calendar and Holidays)

Quick sanity check before you build any of this: are the two timestamps you are comparing both in JSM, both in Jira Software, or mixed? That determines whether option 3 is on the table at all.

Hope this helps.

Bill Sheboy

Hi @Mark W_ McColgan and @Trudy P Claspill

Mark, as you want the business hours diff with holiday handling, I recommend looking for an external REST API endpoint which could be called from an automation rule with the Send Web Request action. Or, if you need this for display-only purposes, check if you have (or could acquire) marketplace dashboard gadgets / reports to help.

Trudy, thanks for finding that old post of mine as it includes many of the relevant assumptions and steps for this scenario!

After you recently answered a similar question, I did a bit of experimentation and created a generic, automation expression to calculate business hours diff between two date / time values. I am still pondering if it would be worth posting as an article; it is a bit tricky / complicated, although it has some helpful dependent features for other rule scenarios...but, it cannot easily handle embedded holidays. (That was another article, I recall :^)

Kind regards,
Bill

Trudy P Claspill

@Bill Sheboy
If you're willing to do the work it might be worth it to write that article, even if the solution is complicated. I'd give it a Like!

Paul Glantschnig _Appfire_

Hi @Mark W_ McColgan, one more option if you want this as a column you can read across many issues at once:

The automation route and the JSM SLA calendars are the right native paths. The trade-off is that automation makes you model holidays yourself and store the result in a field, and SLA calendars only exist in service projects.

If you're open to solutions from the Atlassian Marketplace, JXL for Jira (the app my team and I work on) is a spreadsheet-style view of your issues that includes history columns Jira doesn't expose natively. Your "hours since issue creation" example maps directly to a Time since created column, and you can point it at a work calendar so it counts only working hours and skips non-working days. The same applies to Time between statuses and Time between created and resolved.

Time since issue creation, configurable with a work calendar

Those values are live, sortable, and filterable across the whole sheet, and you can add conditional formatting to flag anything past a threshold.

One honest caveat: for a diff between two of your own custom date fields (rather than created/status timestamps), and for a named holiday set, it's worth a quick confirmation against our docs that the calendar options fit your case.

BR, Paul

Elita Kalāne - eazyBI Support

Hi @Mark W_ McColgan

Disclosure: I work for the eazyBI team.

If you are willing to try an Atlassian Marketplace app, check out eazyBI for Jira Cloud.

eazyBI is a reporting and analytics add-on that lets you build a variety of reports, including what you're describing - calculation of business day difference between issue creation timestamp and now/today.

Here's how it would look:

You can create a calculated measure using the DateDiffWorkHours MDX function. It accepts configurable non-working days and business hour windows.

For business hours between issue creation and now (assuming that the business hours are from 9 am till 5 pm:

DateDiffWorkHours(
  [Issue].CurrentHierarchyMember.Get('Created at'),
  Now(),
  'default',
  '9-17'
)

For business hours between two custom date fields:

DateDiffWorkHours(
  [Issue].CurrentHierarchyMember.Get('Your Start Field at'),
  [Issue].CurrentHierarchyMember.Get('Your End Field at'),
  'default',
  '9-17'
)

The function returns the value in hours. Depending on how you want to display it:

Use #,###.00 Decimal formatting to show hours as a decimal number, e.g. 12.5
If you prefer an h/m display like 12h 30m, multiply the result by 60 and apply the ##h ##m duration format, since that formatter expects minutes:

DateDiffWorkHours(
  [Issue].CurrentHierarchyMember.Get('Created at'),
  Now(),
  'default',
  '9-17'
) * 60

For holidays, eazyBI lets you define non-working days in the Time dimension options in your data import settings. When configured, passing 'default' as the third argument automatically takes those holidays into account.

business days.png

Best,

Elita from support@eazybi.com

Vahtang Manukyan - Be On Time

This is a great technical breakdown of the available options. If you just need a quick calculation for a dashboard, Option 1 or 2 is the way to go.

However, as a word of caution from the consulting side: if you are using these calculations for billing or high-stakes resource reporting, the 'Native Automation' approach (Option 2) creates a significant maintenance burden. Every time a new public holiday is announced or a company-wide day off is added, someone has to manually update that JSON list in your automation rules. In a global organization with multiple regions, this quickly becomes a source of data error.

The 'JSM SLA' approach (Option 3) is the cleanest native path, but as noted, it only works if you're in JSM. If you are in Jira Software and need true 'Enterprise-grade' calendar logic - where the calendar is a central organizational asset rather than a line of code in a rule - that's usually when I recommend moving to a dedicated resource management layer, and there are some good marketplace apps for that. It removes the 'logic' from the automation and places it into a professional calendar engine, ensuring that your business hours are consistent across the entire project, not just in one specific rule.

Technically, the previous answer gives you the 'how', but operationally, the 'where' (where the logic lives) is what determines if this remains a solution or becomes a maintenance chore.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud