---
title: "How to resolve timezone mismatches in SIL scripts on Jira Cloud"
canonical: "https://support.appfire.com/space/SUPPORT/3709009924/How%20to%20resolve%20timezone%20mismatches%20in%20SIL%20scripts%20on%20Jira%20Cloud"
format: markdown
---
## Summary

When you do date arithmetic in SIL scripts on Jira Cloud, your results can have an unexpected time offset, for example, 4 or 5 hours.

This happens because of how Jira Cloud handles dates:

- Jira Cloud stores system fields, such as `created`, `updated`, and `resolutiondate`, in UTC, and its APIs always return them in UTC.
- The Power Scripts time configuration (**Jira Settings** > **Apps** > **Power Scripts** > **Settings** > **Time configuration**) controls SIL functions such as `currentDate()`, but it doesn't change the raw Jira Cloud API values for system fields.
- Custom date fields often store local wall-clock time from when a user entered the value or a workflow transition ran.

When you subtract a local custom date field from a UTC system date in SIL (`updated - customDate`), the interval is off by your instance's UTC offset. Use one of these three approaches to fix it.

---

## Approach 1: Normalize system fields to local time in your script

**Scenario:** You're calculating the difference between a system field (UTC) and a custom date field (local time), and the interval is wrong.

**Solution:** In your script, apply a UTC offset to the system fields so they match your local timezone before you calculate. This example uses the offset for Toronto during daylight saving time (UTC-4):

```sil
// Example for Toronto (EDT: UTC-4)
date assignedDate = #{Assigned- Date of first transition};

// Subtract UTC offset to normalize system fields to local time
interval utcOffset = "4h"; 
date createdLocal = created - utcOffset;
date updatedLocal = updated - utcOffset;

runnerLog("Current Date -> " + currentDate());
runnerLog("Created Date (Raw UTC) -> " + created);
runnerLog("Created Date (Normalized Local) -> " + createdLocal);
runnerLog("Assigned Date -> " + assignedDate);
runnerLog("Updated Date (Raw UTC) -> " + updated);
runnerLog("Updated Date (Normalized Local) -> " + updatedLocal);

// Calculate difference using normalized dates
runnerLog("Difference -> " + (updatedLocal - assignedDate));
interval testInt = updatedLocal - assignedDate;
runnerLog("Interval -> " + testInt);
```

> ℹ️ The `utcOffset` value is your current UTC offset. Update it when daylight saving time starts or ends. For example, use `"4h"` for EDT and `"5h"` for EST.

---

## Approach 2: Store custom dates in UTC (recommended long-term fix)

**Scenario:** Your custom date fields store local wall-clock time, so they don't line up with system-generated UTC timestamps.

**Solution:** Configure the post function or automation rule that populates your custom date field to store a UTC timestamp instead of local wall-clock time. When both fields use UTC, native arithmetic (`updated - customField`) is accurate in all your scripts, and you don't need offset logic.

---

## Approach 3: Calculate intervals using system fields only

**Scenario:** Mixing custom date fields and system fields throws off your elapsed-time tracking.

**Solution:** To track elapsed time or SLA durations, build the interval from system fields only, such as `created`, `updated`, or `resolutiondate`. Jira Cloud stores all system fields in UTC, so calculations between them are always accurate.

---

## Related pages

- [Time configuration](https://appfire.atlassian.net/wiki/spaces/PSJC/pages/2028634113)
- [Simple Issue Language](https://appfire.atlassian.net/wiki/spaces/PSJ/pages/15489652)