Forum Replies Created

Viewing 2 replies - 1 through 2 (of 2 total)
  • Thread Starter mindaugas12365

    (@mindaugas12365)

    @afiyah

    Appreciate the quick response and fix!

    Thread Starter mindaugas12365

    (@mindaugas12365)

    I wanted to follow up with additional findings after further debugging.

    It appears the issue is not that WooCommerce captures the time “too early,” but that the displayed time is being shifted due to a timezone offset being applied twice.

    The meeting’s startDateTime is stored correctly as a timezone-aware ISO 8601 string (for example:
    2026-03-18T19:00:00-04:00).

    Since this string already includes the offset, PHP correctly interprets it when parsed with DateTime or strtotime(). However, the WooCommerce integration logic seems to apply the site gmt_offset (or similar offset math) again before formatting the output. In my timezone (UTC-5 / UTC-4), this results in a 4–5 hour backward shift (e.g., 7 PM displaying as 3 PM).

    To confirm this, I implemented a workaround:

    • I parsed startDateTime using PHP’s DateTime so the embedded offset is respected.
    • I explicitly set the DateTime object to the meeting’s configured timezone before formatting.
    • I overrode the WooCommerce “Meeting Details” tab output.
    • I filtered cart/checkout fragments.
    • I buffered WooCommerce email output and replaced the incorrectly formatted time strings with the correctly formatted ones.

    After doing this, the displayed time is correct everywhere (product page, cart, checkout, emails).


    To illustrate the issue, here is a simplified example of what appears to be happening conceptually:

    Stored value (correct and timezone-aware):

    2026-03-18T19:00:00-04:00

    If parsed normally:

    $dt = new DateTime('2026-03-18T19:00:00-04:00'); echo $dt->format('Y-m-d H:i'); // Correct: 2026-03-18 19:00 in its local timezone

    However, if offset math is applied again after parsing:

    $timestamp = strtotime('2026-03-18T19:00:00-04:00'); $timestamp += get_option('gmt_offset') * 3600; echo gmdate('Y-m-d H:i', $timestamp);

    This shifts the time by the site offset a second time, resulting in a 4–5 hour difference depending on DST.

    In my testing, removing any manual offset adjustment and relying solely on DateTime with the embedded timezone offset resolves the issue completely.

Viewing 2 replies - 1 through 2 (of 2 total)