> ## Documentation Index
> Fetch the complete documentation index at: https://docs.symmetry.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Timezones

> Set an employer's timezone from the ten supported values and interpret I-9 dates correctly. Covers the supported list, calendar dates vs. timestamps, and why date boundaries affect compliance.

Every employer in Symmetry I-9 has a timezone, set from a fixed list of ten values. Because Form I-9 compliance is measured in calendar days rather than hours, the timezone establishes the local frame of reference for an employer's records: which day an employee signed Section 1, whether Section 2 was countersigned within three business days, and when a document is treated as expiring.

## Supported timezones

Symmetry I-9 supports the following timezones, covering the United States and its territories:

| Timezone identifier   | U.S. time zone       | Notes                                      |
| --------------------- | -------------------- | ------------------------------------------ |
| `America/Puerto_Rico` | Atlantic Time        | Also used for the U.S. Virgin Islands      |
| `America/New_York`    | Eastern Time         |                                            |
| `America/Chicago`     | Central Time         |                                            |
| `America/Denver`      | Mountain Time        | Observes daylight saving time              |
| `America/Phoenix`     | Arizona              | Mountain Time without daylight saving time |
| `America/Los_Angeles` | Pacific Time         |                                            |
| `America/Juneau`      | Alaska Time          |                                            |
| `Pacific/Honolulu`    | Hawaii-Aleutian Time | Does not observe daylight saving time      |
| `Pacific/Guam`        | Chamorro Time        | Also used for the Northern Mariana Islands |
| `Pacific/Apia`        | Samoa Time           |                                            |

## Setting an employer's timezone

The `timezone` field is required when [registering a new employer](/i9/getting-started/configure-employers) and can be changed later by [updating the employer](/i9/getting-started/configure-employers). Set it to the timezone where the employer's I-9 activity takes place, typically the worksite or the location of the administrators who countersign.

```json theme={null}
{
  "name": "Example Company",
  "federalEIN": "98-7654321",
  "timezone": "America/New_York"
}
```

The value must be one of the ten identifiers above. Any other IANA timezone, such as `UTC` or `America/Detroit`, is rejected with a validation error naming the accepted values. If you support employers across several regions, map your own location data to the closest supported timezone rather than passing an arbitrary identifier.

<Note>
  Timezone is an employer-level setting; it is not configured per employee or per administrator. Employers operating in multiple time zones are typically modeled as separate employer records when their I-9 records need to be evaluated against different local dates.
</Note>

## Interpreting dates and timestamps

The API returns two distinct kinds of temporal values, and treating one like the other is the most common source of off-by-one-day errors.

**Calendar dates** carry no time or offset. These are the dates recorded on the form itself, including `dateOfBirth`, `employeeStartDate`, `employeeSignDate`, `employerCertifyDate`, `documentationExpirationDate`, and `reverifyExpirationDate`. Store and display them as-is.

```json theme={null}
{
  "employeeStartDate": "2026-03-02",
  "documentationExpirationDate": "2027-06-30"
}
```

**Timestamps** are ISO 8601 values with an explicit UTC offset. These record when an action occurred in the system and include `submittedAt`, `statusChangedAt`, `resolvedAt`, the `serverTimestamp` on [audit log entries](/i9/compliance-and-audit-readiness/audit-logs), and the `timestamp` on [webhook payloads](/i9/core-concepts/webhooks).

```json theme={null}
{
  "serverTimestamp": "2026-05-28T10:49:10-04:00"
}
```

<Warning>
  Always parse the offset that a timestamp carries rather than assuming a fixed zone, and normalize to UTC before sorting or comparing. Offsets can differ between entries in the same audit log, so a string comparison or a naive parse can put events in the wrong order.
</Warning>

Converting a calendar date as though it were a midnight timestamp is what produces day shifts. An `employeeStartDate` of `2026-03-02` read as `2026-03-02T00:00:00Z` and then displayed in Pacific Time becomes March 1, which changes what your system reports about when the employee began work.

## Why this matters for compliance

Form I-9 deadlines are defined in days, so the date an action is attributed to is what determines whether the record is timely:

* **Section 1** must be completed no later than the employee's first day of employment.
* **Section 2** must be completed within three business days of the employee's start date. When certification happens later, the completed form carries a `lateReason` explaining the delay, which becomes part of the record you produce in an audit.
* **Reverification and expiring documents** are driven by calendar dates. The [`employee.upcomingExpiration` webhook](/i9/core-concepts/webhooks) fires 30 days ahead of a document's expiration date, so consistent date handling keeps your reminders aligned with the dates on the form.

During an [ICE inspection](/i9/compliance-and-audit-readiness/ice-audits), the audit log is the evidence of who did what and when. Rendering those timestamps consistently in the employer's timezone means the sequence you present matches the sequence a reviewer reconstructs from the forms.