Question
Fixed offset slider vs. host system timezone for stable regional time display in After Effects
Kavi Vale
0 reputation · 01 Feb 2024, 18:42 UTC
125.1K views1
Loading…
0 reputation · 01 Feb 2024, 18:42 UTC
When a project must render a text layer showing a specific regional time that remains consistent across workstations, the documented options create a trade-off between portability and maintenance. One approach relies on the expression language’s Date object and the host system’s locale, optionally attempting to pass an IANA identifier to toLocaleString. Another approach stores a fixed UTC offset in a slider control and applies it manually, avoiding dependence on the host timezone.
The uncertainty is that After Effects does not ship an IANA timezone database, and older versions reportedly ignore the timeZone option in expression date formatting, falling back to the host locale. ExtendScript can read the operating system timezone via environment variables or getTimezoneOffset(), but those values reflect the host machine and cannot be overridden per project without external libraries. The fixed-offset method avoids cross-machine drift but requires manual updates when daylight-saving rules change.
Assuming the documented behavior still applies to current releases, which approach is appropriate for a project that must display a fixed regional time on both Windows and macOS without shifting when opened on a machine in a different timezone? Does any current version of After Effects respect the timeZone argument in expressions, or is the slider-based offset still the only reliable documented method? If the timeZone option is supported, what is the earliest version where it consistently honors an IANA identifier rather than falling back to the host locale?
35275 reputation · 02 Feb 2024, 02:39 UTC
For projects requiring a consistent regional time across different workstations (Windows and macOS), the fixed-offset slider method is the only reliable approach. Current versions of After Effects do not consistently honor the timeZone argument in toLocaleString(), meaning the expression engine falls back to the host system's locale and timezone. To ensure portability, you must manually calculate the offset and apply it to the Date object using UTC methods.
The After Effects expression engine lacks a built-in IANA timezone database. While the JavaScript Date object is available, its formatting methods are tied to the operating system's environment. Because the timeZone option in toLocaleString() is typically ignored, a project opened in London will render a different time than the same project opened in New York if it relies on the host system.
By using a slider to store a numeric offset (e.g., in minutes) and applying it to the UTC timestamp, you bypass the host's local time settings entirely. This creates a deterministic output regardless of the machine's regional settings.
aftereffectsUTC Offset.-300 for EST/UTC-5).var offset = effect("UTC Offset")("Slider"); // Offset in minutes
var now = new Date();
// Convert current time to a pure UTC timestamp
var utcMillis = now.getTime() + (now.getTimezoneOffset() * 60000);
// Apply the fixed slider offset
var regionalDate = new Date(utcMillis + (offset * 60000));
function pad(n) { return n < 10 ? '0' + n : n; }
pad(regionalDate.getUTCHours()) + ":" + pad(regionalDate.getUTCMinutes());To verify this setup, open the project on two machines with different system timezones. If the rendered text remains identical, the offset is correctly decoupled from the host OS.
If you are using a version of After Effects released after 2024, please provide the specific version number. While unlikely, a change in the underlying JavaScript engine could introduce IANA support; you can test this by running new Date().toLocaleString('en-US', {timeZone: 'Asia/Tokyo'}) on two different machines to see if the output diverges.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 01 Feb 2024, 20:16 UTC
The core issue is that new Date() and toLocaleString() in AE expressions always fall back to the host OS clock. Even the timeZone option is silently ignored in all publicly documented releases up to AE 2024.1, so a project opened on a machine in a different zone will show a different local time.
For regions that observe daylight‑saving, the fixed‑offset slider can be extended with a tiny lookup table. Store two offsets (standard and DST) and use a date‑comparison to pick the correct one:
var stdOffset = -300; // UTC‑5 for EST
var dstOffset = -240; // UTC‑4 for EDT
var now = new Date();
var utc = now.getTime() + (now.getTimezoneOffset() * 60000);
// Approximate DST window: second Sunday in March to first Sunday in November
var year = now.getFullYear();
var dstStart = new Date(year, 2, 8 + (7 - new Date(year, 2, 1).getDay()));
var dstEnd = new Date(year, 10, 1 + (7 - new Date(year, 10, 1).getDay()));
var offset = (now >= dstStart && now < dstEnd) ? dstOffset : stdOffset;
var regional = new Date(utc + offset * 60000);
Embed this logic in the same slider‑controlled expression so the rendered time stays correct regardless of the workstation’s zone.
After adding the DST logic, open the project on two machines set to different time zones and compare the rendered text. If the times match the target region’s current offset, the approach works. Remember to update the DST window rules if your project spans multiple years or if the region’s legislation changes.