Skip to main content
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:

​
Setting an employer’s timezone

The timezone field is required when registering a new employer and can be changed later by updating the employer. 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.
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.
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.

​
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.
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, and the timestamp on webhook payloads.
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.
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 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, 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.