Dates and Times

Coordinating a partner's delivery deadline with a scheduled transfer means knowing which time zone each uses. Files.com records timestamps in Coordinated Universal Time (UTC), while time zone settings determine how people see those timestamps and when scheduled work becomes due.

Your display preference, a workflow's schedule, and the date used in a generated filename are separate choices. For a nightly partner feed, those choices let the transfer follow the partner's business day while your team reviews its activity in its own local time.

UTC and Time Zones

UTC provides a shared reference for an instant in time. It does not change for daylight saving time. Converting a timestamp to another time zone changes its displayed date and time, while preserving the instant it represents. The same event can fall on different calendar dates for people in different zones.

A named time zone includes the rules for a location, including seasonal clock changes where they apply. Files.com accepts names such as Eastern Time (US & Canada) and IANA time zone identifiers such as America/New_York. The applicable offset depends on the date being represented. A January timestamp uses January's offset even when you view it in July.

A fixed UTC offset, where a setting accepts one, describes a constant difference from UTC. For example, -05:00 stays five hours behind UTC throughout the year. It does not follow Eastern Time into daylight saving time. Choose a named zone when work needs to follow a location's clock, and UTC when it needs to follow a constant worldwide reference.

Display and Date Entry

Your Time Zone setting controls timestamp display in the web interface, including the File Manager and activity tables. Two users can see different local times for the same event. The language setting also affects how dates and times are formatted.

Site Administrators set Default New User Time Zone to preselect a zone on the new-user form. Each user retains their own setting. This default does not supply a time zone for every workflow on the site. User Time Zones covers user configuration.

Date and time pickers in the web interface interpret your selection in your time zone. For example, selecting a Share Link expiration of 5:00 PM means 5:00 PM in that zone on the selected date, with the offset applicable to that date. Once saved, the expiration represents one instant; another user sees that same expiration in their own zone.

Some tables can display relative ages, such as two hours ago, instead of dates and clock times. Absolute dates are useful when comparing an event with another system's records.

Activity timestamps in folder email notifications use the recipient's time zone. The user's Daily email notification send time also follows that user's zone. When no user zone is set for daily delivery, the site's default is used before the notification system's Eastern Standard Time fallback.

Scheduled Work

The time zone on a schedule determines its local days and times. An Automation scheduled for Monday at 3:00 PM Eastern follows Monday and 3:00 PM in Eastern Time, even when it is already Tuesday somewhere else. Changing the viewing user's time zone does not change that schedule.

This applies to scheduled Automations v1 and v2, Syncs, AI Tasks, Expectations, and Scheduled Report Exports. When work uses a saved Schedule, that Schedule supplies the days, times, time zone, and Holiday Region. Otherwise the work's own schedule settings apply. An Expectation's scheduled time is its delivery deadline.

Scheduled times without a time zone are interpreted as UTC. Automation and Sync interval schedules without a time of day run at midnight UTC. Set both the time and the zone explicitly when a local business deadline matters. The Automation and Sync trigger references explain their scheduling choices.

A Sync's Automatic Interval (in minutes) is an elapsed interval, such as every 60 minutes. A Schedule Interval, despite its similar name, follows calendar days such as the first of each month. These choices serve different requirements: elapsed intervals repeat after a duration, while a calendar schedule follows the selected date and clock time.

A scheduled time makes work due. Queueing, concurrency limits, and work already running can affect when it starts or finishes. A scheduled transfer time therefore does not establish when the receiving application has finished processing the file.

Daylight Saving Time (DST)

Schedules in a named time zone follow that zone's daylight saving rules automatically. A Sync or Automation scheduled for 3:00 PM Eastern continues to become due at 3:00 PM Eastern in both standard time and daylight saving time. Its UTC time changes with the offset.

There is no need to edit a named-zone schedule for the seasonal change. A UTC schedule stays at the same UTC time, so its local time changes in places whose clocks change. Locations can change clocks on different dates or leave them unchanged, so two partner systems can temporarily have a different time difference from the one they usually have.

For scheduled Automation, Sync, AI Task, and Scheduled Export triggers, the clock-change window itself has two consequential cases:

• When clocks move forward, a local time that is skipped has no scheduled occurrence that day. For example, a 2:30 AM New York schedule does not run on a day when the clock jumps from 2:00 AM to 3:00 AM. It is not moved to 3:30 AM.
• When clocks move backward, a local time in the repeated period matches twice. A 1:30 AM New York schedule matches both occurrences, an hour apart. It can trigger work twice, subject to the feature's normal handling of overlapping runs.

Scheduled Expectations resolve each selected due time to one delivery deadline. In New York, a 2:30 AM deadline moves to 3:30 AM on the spring-forward day, and a 1:30 AM deadline uses the first occurrence on the fall-back day. Delivery and late windows are elapsed durations measured from that deadline.

Choose a local time outside the clock-change window when a business process needs one occurrence on every scheduled day. Choose UTC when a constant UTC time is the requirement. A daily local schedule can have 23 or 25 elapsed hours between occurrences across a one-hour clock change; it is different from a repeating 24-hour duration.

Calendar Dates and Holidays

A calendar date identifies a day, rather than an instant shared worldwide. Monthly and yearly schedules use the calendar in their schedule's time zone. A monthly run on day 31 is skipped in months without a 31st; it is not moved to the last day. An end-of-month schedule follows the actual final day, including February 29 in a leap year.

Holiday Region and Holiday Calendars exclude scheduled occurrences. A Holiday Calendar carries dates and optional partial-day windows, but no time zone of its own. Its dates and windows are interpreted in the consuming schedule's zone. With no schedule zone, holiday evaluation falls back to the site's default time zone, then UTC. This holiday fallback is separate from the UTC default for scheduled times.

A partial-day closure follows local clock time too. It excludes both occurrences of a repeated time that falls within the closure. A full-day closure excludes the local calendar day, whether that day is shorter or longer than 24 hours.

Timestamps in File and Folder Names

A dated name needs a business-date rule of its own. A file received shortly after midnight UTC can still belong to the preceding day in a partner's time zone. Your display setting does not determine which date Files.com puts into its name.

Renaming Uploaded Files, Automatic Subfolder Organization, and Inbox submission folders have their own time zone options for date and time patterns. These use UTC when no zone is selected. The date source also matters: organization by a file's supplied modification date can produce a different folder from organization by its upload date.

Automations have a separate Path Time Zone. It takes precedence over the schedule's zone for the run time used in dated paths; without either, UTC applies. In Automations v1, date placeholders use that run time. In Automations v2 templates, select and format the run's time explicitly when the name needs to belong to the scheduled run.

TransformScript's reference time zone is UTC across file transformations, Automations, and Expectation content validation. Its current-date functions do not inherit the user's, site's, or schedule's zone. A script needing a local business date must convert to that zone explicitly. A date without a time or zone remains a calendar date; it does not acquire a location merely because the work runs there.

File Times, Expiration, and Connected Systems

A file's modification timestamp can come from the uploading system. It can therefore precede its arrival on Files.com. The File Manager's timestamp definitions distinguish upload time, modification on Files.com, and modification supplied by the source. Use the relevant activity record when establishing when a transfer occurred.

An expiration timestamp, such as a Share Link's end time, is a deadline at a specific instant. An age-based rule, such as File Expiration, follows that feature's age calculation and deletion schedule. File Expiration checks file age once per day; it is not a promise to delete a file at a particular local clock time. Changing a display preference does not extend either kind of deadline.

Desktop applications, protocol clients, and connected storage can format timestamps according to their own settings. API responses, exported records, and event messages also have timestamp formats independent of your web interface display setting. Programmatic integrations follow the formats in Files.com developer documentation.

When comparing records across systems, compare the same kind of event and retain the date, time, and UTC offset or time zone. In a repeated local hour, the offset distinguishes the two occurrences. A date embedded in a filename or inside a file is data, rather than proof of when Files.com received it. Time zone display settings do not convert dates inside file contents; use an explicit transformation when the exchanged data needs that conversion.