Inconsistent scene timestamps when opening .max files on different time zones

Direct Answer

3ds Max writes the scene's creation and modification timestamps into the .max file as local-time values (derived from the Windows FILETIME structure but interpreted without an embedded time-zone offset). When the same file is opened on a machine in a different zone, 3ds Max and MaxScript report those raw values converted to the current machine's local zone, so the displayed time shifts. There is no native preference, INI setting, or MaxScript property to make 3ds Max store or display these timestamps in UTC.

Confirmed Behavior

• Storage: The .max file contains two 64-bit integers representing local file time at save. No timezone metadata is recorded.
• Display in UI: File > Properties shows the timestamps converted to the OS zone of the machine opening the file.
• MaxScript queries: getFileCreationTime() and getFileModificationTime() return locale-formatted strings in the current machine's zone. systemDateTime and dateTime likewise return the executing machine's local time — they do not reflect the file's original save zone.
• Backburner logs: Job submission, start, and completion times are written by the Manager or Worker service using that service's local clock. A job submitted from UTC-8 and executed on a UTC+2 worker will show two different local-time ranges in the same log.

Practical Mitigations

1. Embed explicit UTC metadata at save time

Add a filePostOpen (or filePreSave) callback that writes an ISO-8601 UTC string into the scene's user properties or appData chunk:

callbacks.addScript #filePreSave "
    local utc = (dotNetClass \"System.DateTime\").UtcNow.ToString(\"o\")
    setUserPropBuffer maxFile \"utcSaveTime\" utc
"

Read it later with getUserPropBuffer maxFile "utcSaveTime" — the value is identical on every workstation regardless of zone.

2. Rely on version-control timestamps

Perforce, Git LFS, Plastic SCM, etc. record check-in time in UTC on the server. If your pipeline can query the VCS API instead of the .max file's internal timestamps, you avoid the ambiguity entirely.

3. Normalize in automated pipelines

Treat the native timestamps as opaque local-time strings. When a script needs to compare or sort scenes, parse the embedded UTC metadata (from step 1) or the VCS timestamp, not getFileModificationTime().

Verification Steps (Run Once Per Environment)

1. Save a test .max on a machine set to UTC-8. Note the timestamp in File > Properties.
2. Copy the file to a machine set to UTC+2. Open it and observe the shifted timestamp in Properties.
3. Run print getFileModificationTime "path\\scene.max" on both machines; the strings will differ by the zone offset.
4. Add the callback above, re-save, then read getUserPropBuffer maxFile "utcSaveTime" on both machines — the ISO string matches exactly.
5. Submit a Backburner job from the UTC-8 machine to a UTC+2 worker; open Manager > Jobs > View Log and confirm the log timestamps follow each machine's local clock.

One Diagnostic Detail That Changes the Recommendation

Does your pipeline already have a standardized scene-save script (or asset-manager hook) that runs on every artist's machine? If yes, inject the UTC metadata there. If no, you'll need to deploy a userSetup.ms or Plugin.Ini entry to install the callback globally — let me know which deployment path you prefer and I can outline the exact steps.