Haxe Date regional time zone and DST behavior across targets

Question

Cross-Target Time Zone Consistency
Haxe provides the Date type and DateTools for handling timestamps. While the standard library allows for UTC accessors and host-local wall time, the behavior of local getters and the full-argument constructor depends on the target runtime's environment.
Because Haxe does not define a built-in IANA time zone database or standardized DST rules, identical source code may produce different wall-clock values when compiled for different targets or executed on hosts with varying regional settings. This creates uncertainty when normalizing date-time data at I/O boundaries versus the presentation layer.
Technical Constraints

Lack of a standard API to load specific IANA zones.
Dependence on host platform for DST transition logic.
Target-dependent behavior for Date.fromString and DateTools.format regarding locale calendars.

Does Haxe provide a mechanism to ensure consistent regional offset calculations across different targets without relying on the host OS? How should developers handle DST transitions to maintain portability across runtimes?

Tasadduq Burney · Answer

Direct answer
No. Haxe's standard library does not include an IANA time-zone database, and it offers no portable API that forces one specific regional offset or DST rule across all targets. Local wall-time getters, UTC offsets, and DST transitions are resolved by the target runtime and the host operating system, so identical Haxe source can produce different wall-clock values on JavaScript, server, mobile, or desktop builds.
Confirmed behavior and assumptions
The following applies to Haxe 4.x unless your target bindings document otherwise. Exact accessor names and zone-ID formats are target- and runtime-version-sensitive and should be verified against your target documentation.

Date.now() and epoch-millisecond values denote the same UTC instant on every target.
Local hour, minute, and offset getters read the host's configured time zone.
DST spring-forward gaps and fall-back repeats follow the host zone database, not Haxe source code.
Date.fromString and DateTools.format handling of zone names and locale calendars varies by target.

Steps for portable date handling

Store and exchange instants as epoch milliseconds or ISO-8601 strings in UTC.
Perform comparisons and arithmetic on UTC instants; never treat a naive local wall-clock time as unambiguous across DST boundaries.
Convert to regional wall time only at the presentation layer, using the target's native time-zone API.
If identical zone rules are required on every target, bundle a time-zone database or use a target-specific time-zone library instead of relying on the host OS.
Around DST transitions, resolve nonexistent or repeated local times explicitly with the target zone rules.

Practical verification
Confirm your toolchain:
haxe --version
Compile the same source for each target with the host time zone set to UTC, then to a DST-observing region. Epoch values must remain equal, while local hour, offset, and DST flag may change.
Missing diagnostic detail
Which Haxe targets and Haxe version are you compiling for? That detail determines which target-specific time-zone API or library is appropriate.

Haxe Date regional time zone and DST behavior across targets

Cross-Target Time Zone Consistency

Technical Constraints

1 answer

Direct answer

Confirmed behavior and assumptions

Steps for portable date handling

Practical verification

Missing diagnostic detail

Your perspective belongs here.

0 question comments