Problem

Jira Automation provides a useful set of date and time smart-value operations for manipulating dates inside automation rules.

For example, Automation already supports concepts such as week numbers, weekday manipulation, month boundaries, date addition, date subtraction, and time-zone conversion.

However, there does not appear to be a direct, first-class date smart-value operation for answering a very common calendar question:

What are the first and last dates of the week containing this date?

Conceptually, it would be useful to support operations such as:

{{now.startOfWeek}}
{{now.endOfWeek}}

and the same operations for dates coming from issues:

{{issue.created.startOfWeek}}
{{issue.created.endOfWeek}}

{{issue.updated.startOfWeek}}
{{issue.updated.endOfWeek}}

{{issue.duedate.startOfWeek}}
{{issue.duedate.endOfWeek}}

This would make weekly date calculations considerably easier to read, maintain, and audit.

Why this is useful

Weekly boundaries are a basic temporal primitive in many real Jira Automation workflows.

Examples include:

• weekly reports
• recurring issue creation
• scheduled planning rules
• sprint naming
• release-window calculations
• weekly reminders
• weekly summaries
• date-range calculations
• custom date-field values
• integration payloads
• filenames generated by Automation
• reporting-period labels
• recurring maintenance tasks
• SLA-related reporting logic
• week-based exports
• cross-month planning workflows

In each of these cases, a rule may start with an arbitrary date and need to calculate the week containing that date.

At the moment, rule authors may need to reconstruct this operation manually from lower-level date functions.

A native week-boundary operation would communicate the intent directly.

Compare:

{{issue.duedate.startOfWeek}}

with a longer expression composed from weekday detection, addition, subtraction, or weekday-changing functions.

The first expression immediately communicates what the rule is doing.

Current Workaround

Without a dedicated week-boundary operation, users may need to construct a calculation using combinations of functionality such as:

withDayOfWeek()
withNextDayOfWeek()
plusDays()
minusDays()

For simple cases this may be possible.

However, the rule author must then encode several assumptions manually:

• Which weekday begins the week?
• Is Monday the first day?
• Is Sunday the first day?
• What happens when the result crosses a month boundary?
• What happens when the result crosses a year boundary?
• Is the date being evaluated before or after a timezone conversion?
• Is the expression calculating a civil-date boundary or manipulating an instant?

These questions make a conceptually simple operation harder to reason about than necessary.

Concrete Example

Consider the date:

2027-08-18

This date falls on a Wednesday.

For a Monday-first calendar, the containing week is:

2027-08-16 -> 2027-08-22

For a Sunday-first calendar, the containing week is:

2027-08-15 -> 2027-08-21

The source date has not changed.

Only the definition of the week boundary has changed.

This is an important distinction because calendar date identity and calendar presentation rules are separate concerns.

A first-class Automation operation could make that distinction explicit rather than requiring every rule author to reconstruct it manually.

Suggested Functionality

Provide first-class date smart-value operations representing the start and end of the week containing a given date.

For example:

{{date.startOfWeek}}
{{date.endOfWeek}}

Examples using common Automation values:

{{now.startOfWeek}}
{{now.endOfWeek}}

{{issue.created.startOfWeek}}
{{issue.created.endOfWeek}}

{{issue.updated.startOfWeek}}
{{issue.updated.endOfWeek}}

{{issue.duedate.startOfWeek}}
{{issue.duedate.endOfWeek}}

This would allow the same operation to be applied consistently to different date sources.

Optional Explicit Week-Start Argument

If feasible, it would be even more useful for Automation to allow the desired week convention to be stated explicitly.

For example, conceptually:

{{date.startOfWeek("MON")}}
{{date.endOfWeek("MON")}}

or:

{{date.startOfWeek("SUN")}}
{{date.endOfWeek("SUN")}}

The exact syntax is not important to this suggestion.

Alternatives could include:

{{date.startOfWeek(1)}}
{{date.endOfWeek(1)}}

or another API shape that fits the existing Automation date API.

The important requirement is that the behavior is deterministic and clearly documented.

Why Explicit Week Semantics Matter

A "week" is not only seven consecutive dates.

Applications must also decide where that week begins.

For example, assume a month begins on Sunday.

A Sunday-first calendar may treat that date as the beginning of a new visible week.

A Monday-first calendar places the same Sunday at the end of the previous Monday-based week.

Neither interpretation changes the underlying date.

Only the boundary convention changes.

That is why a reusable week-boundary primitive should either:

• use a clearly documented Jira week-start convention, or
• allow the caller to specify the desired first weekday explicitly.

It should not require users to discover the convention through trial and error.

Calendar Boundary Example - August 2027

August 2027 provides a useful example because August 1, 2027 falls on a Sunday.

A simplified Sunday-first representation begins:

Sun Mon Tue Wed Thu Fri Sat
  1   2   3   4   5   6   7
  8   9  10  11  12  13  14
 15  16  17  18  19  20  21

For a Monday-first interpretation, that same August 1 belongs to a week whose Monday falls in the previous month.

This creates exactly the sort of boundary condition where an explicit week API is easier to reason about than manually constructed offsets.

Human-readable visual reference:

August Calendar

General Gregorian calendar reference:

Beta Calendars

These external pages are provided only as human-readable visual references for manually checking the calendar geometry.

The proposed Jira Automation feature should use Jira's own date/time implementation and should have no dependency on an external calendar service.

Month Boundary Behavior

The operation should work correctly when the containing week spans two months.

For example, consider a date near the beginning of a month.

A Monday-first calculation may return a start date located in the previous month:

Source date:
2027-08-01

Possible Monday-first containing week:
2027-07-26 -> 2027-08-01

The month transition should not require special handling by the Automation author.

Similarly, a date near the end of a month may produce an end-of-week value located in the following month.

The operation should treat this as ordinary calendar arithmetic.

Year Boundary Behavior

The same principle applies at year boundaries.

For example, a week containing late December may extend into January of the following calendar year.

Conceptually:

December date
      |
      v
startOfWeek ---------------- endOfWeek
                               |
                               v
                         January date

A native operation should handle this transparently.

Rule authors should not need special December/January branches simply because the week crosses the calendar-year boundary.

Time Zone Considerations

Automation supports workflows where date/time values may be converted between time zones.

Week-boundary behavior should therefore be clearly defined relative to timezone conversion.

For example, these two conceptual operations may not necessarily mean the same thing:

convert timezone -> determine calendar week

and:

determine calendar week -> convert resulting timestamp

For date/time smart values, documentation should make the evaluation order clear.

The important requirement is deterministic behavior.

A rule should not unexpectedly move to a different civil week simply because an undocumented timezone assumption was applied.

Proposed Examples

Current date

{{now.startOfWeek}}
{{now.endOfWeek}}

Issue creation date

{{issue.created.startOfWeek}}
{{issue.created.endOfWeek}}

Issue due date

{{issue.duedate.startOfWeek}}
{{issue.duedate.endOfWeek}}

Custom date field

Conceptually:

{{issue.customfield_XXXXX.startOfWeek}}
{{issue.customfield_XXXXX.endOfWeek}}

Explicit Monday-first calculation

If configurable week starts are supported:

{{issue.duedate.startOfWeek("MON")}}
{{issue.duedate.endOfWeek("MON")}}

Explicit Sunday-first calculation

{{issue.duedate.startOfWeek("SUN")}}
{{issue.duedate.endOfWeek("SUN")}}

Benefits

Adding a dedicated week-boundary operation would provide several benefits.

1. More readable Automation rules

A rule containing:

{{issue.duedate.startOfWeek}}

is self-explanatory.

A multi-step expression reconstructing the same date from weekday offsets requires considerably more context.

2. Less duplicated date arithmetic

Individual teams would no longer have to independently recreate the same week-boundary calculation.

3. Fewer calendar edge-case errors

A shared Jira implementation can consistently handle:

• month transitions
• year transitions
• different month lengths
• leap years
• timezone behavior
• weekday conventions

4. Easier rule maintenance

Future administrators can understand the purpose of the calculation without reverse-engineering a chain of date transformations.

5. Better consistency with Jira concepts

Jira users are already familiar with the concepts of week starts and week ends from other date-related Jira functionality.

Exposing equivalent concepts in Automation date smart values would make weekly date manipulation easier to discover.

6. Better integration workflows

Integrations frequently need explicit date ranges:

{
  "periodStart": "2027-08-16",
  "periodEnd": "2027-08-22"
}

Native week-boundary values would simplify generation of payloads like this.

Suggested Acceptance Criteria

1. A supported Jira date/time smart value can return the beginning of its containing week.

1. A supported Jira date/time smart value can return the end of its containing week.

1. The operations work with commonly used sources including the current date/time, issue creation date, issue update date, due date, and compatible custom date fields.

1. The documented behavior clearly identifies which weekday is considered the beginning of a week.

1. If configurable week starts are supported, the caller can explicitly request a supported weekday.

1. Calculations work correctly when a week crosses a month boundary.

1. Calculations work correctly when a week crosses a calendar-year boundary.

1. Leap years do not require any special handling by the Automation author.

1. Timezone behavior is deterministic and documented.

1. Existing Automation date smart values remain backwards compatible.

1. The resulting value can continue to use existing date-formatting functions.

1. The feature does not require any external calendar service.

Example Expected Result

Given:

Source date: 2027-08-18
Week start: Monday

the expected result would conceptually be:

startOfWeek = 2027-08-16
endOfWeek   = 2027-08-22

With Sunday configured as the first weekday:

startOfWeek = 2027-08-15
endOfWeek   = 2027-08-21

The original date remains:

2027-08-18

Only the requested calendar boundary differs.

Summary

The requested functionality is a small API addition, but it represents a frequently needed calendar primitive.

Instead of requiring each Jira Automation rule to manually reconstruct the weekly boundary of a date, Automation could expose that operation directly.

Conceptually:

date
 |
 +--> startOfWeek
 |
 +--> endOfWeek

This would make weekly automations easier to read, easier to maintain, and less vulnerable to calendar boundary mistakes.

The central request is therefore:

{{date.startOfWeek}}
{{date.endOfWeek}}

with clearly documented week-start semantics and, ideally, an optional way to explicitly select the desired first weekday.