Create a working calendar
A calendar is three things: the days your team works, the days they do not, and a time zone. Nothing else. It is not a leave system and it does not track individual people.
Find it at Settings → Apps → Working Days.
Name
You will pick this name from a dropdown inside the rule builder, months from now,
probably in a hurry. Norway Support and UK Delivery are good names.
Calendar 2 is not. Up to 60 characters.
If you delete a calendar that a rule still uses, the rule stops and tells its owner "Calendar 'Norway Support' no longer exists." — which is why the name is worth getting right.
Working week
Tick every weekday the team normally works. Any combination is allowed:
| Team | Ticked |
|---|---|
| Most of Europe and the Americas | Monday–Friday |
| Parts of the Gulf | Sunday–Thursday |
| Retail and support desks | Monday–Saturday |
| A weekend-only rota | Saturday, Sunday |
At least one day must be ticked. A calendar with no working days can never produce an answer, so it is refused rather than accepted and left to fail later.
Days you do not work
One date per line, written year-month-day:
2026-12-24
2026-12-25
2026-12-26
2027-01-01
You can paste a whole list at once — from a spreadsheet, from a colleague's message, from your government's holiday page. Commas and semicolons work as separators too. Duplicates are removed and the list is sorted for you.
Put anything here that stops work: public holidays, company shutdowns, an office move, a team offsite.
A holiday that falls on a weekend costs you nothing. If 17 May lands on a Sunday, listing it changes no calculation. List holidays as they are published and let the calendar work it out.
Up to 2,000 dates per calendar, which is roughly five years of holidays. Most teams keep the current year and the next.
Getting your holiday list
There is no import in this version and no automatic holiday feed. That is deliberate: an automatic list that is subtly wrong for your office is worse than a short one you typed yourself and trust. Most teams paste ten to fifteen dates once a year.
Time zone
Pick the zone the team actually sits in. It is recorded so you can tell your calendars apart, and it is there for future features that need it.
It never changes a calculation. Dates are used exactly as your rule supplies
them — feed in 17 March and you get answers based on 17 March, wherever anyone is.
For "today", use Jira's own {{now.jiraDate}}, which follows your Jira site's time
zone.
We would rather tell you that plainly than let you assume this field is doing something it is not.
How many calendars
One per group of people who share a working week and a holiday list. A company with a Norwegian support desk, a UK delivery team and a Gulf office needs three. A company with one office needs one.
Up to 50 per site.
Editing and deleting
Editing takes effect on the next rule run. There is nothing to republish.
Deleting is not blocked, because working out which of your rules reference a calendar would mean reading your rules, and this app deliberately has no permission to do that. Instead, any rule still using a deleted calendar stops cleanly and names the calendar in its failure — nothing silently produces a wrong date.
Outside Europe and North America
The app hard-codes no weekend, no holiday and no country. A calendar is whatever you tick and whatever you paste, so these all work the same way:
| Working week | |
|---|---|
| Most of Europe and the Americas | Monday–Friday |
| Gulf states, historically | Sunday–Thursday |
| Israel | Sunday–Thursday |
| Nepal | Sunday–Friday |
| Iran | Saturday–Wednesday |
| Afghanistan | Saturday–Thursday |
| Retail, support desks | Monday–Saturday |
| Weekend rota | Saturday–Sunday |
All 127 possible combinations of the seven days are tested, as is every time zone your Jira knows about — 419 of them.
Holidays are just dates, so religious holidays that move against the Gregorian calendar — Eid, Diwali, Lunar New Year, Easter — work exactly like fixed ones. You list next year's dates when they are announced, the same as everyone else.
Four limits worth knowing
Dates must be Gregorian, written year-month-day. If you work in the Hijri, Solar Hijri, Bikram Sambat or Ethiopian calendar, convert before entering. Jira itself stores Gregorian dates, so this is the platform's constraint as much as ours.
Local date formats are read only once you say which one you mean. 03/04/2026 is
3 April in most of the world and 4 March in the United States, and nothing in the
string settles it. Your Jira's date setting cannot settle it either — that describes
how Jira draws dates on its own screens, not how the value arriving at the action was
written, and the two are often different. So each action carries a Date format
setting. Leave it on year-month-day, which is what every Jira smart value already
produces, or tell it your dates are day-first or month-first. Until you do, a local
date is refused rather than guessed at. 2026-03-17 is understood whichever option
you choose, so smart values keep working either way.
There are no half days. Friday is a half day in parts of the Gulf and in Israel, as Saturday is in parts of Latin America. A day here is either worked or not. If your Friday is a half day, decide which it is for deadline purposes and tick accordingly.
This settings page speaks six languages — English, Norwegian, German, French, Spanish and Brazilian Portuguese — and follows your Jira language.
The rule builder is English. Jira does not allow an app to translate an automation action's name or description, so "Calculate Working Date" and the line under it are English for everyone, in every language. Translating only the form beneath them would put two languages inside one card, so the form is English too and the card reads as one piece. Failure messages are English as well.
That is the whole of it: settings in your language, rule building in English.