Yahoo is not converting UTC to user's calendar timezone format

[Rutulpatel7077]

ST = 20201231T193000 - 7:30 PM
ST = 20201231T193000Z is also showing same time

here is the. URL(s):

Does not includes (Z): https://calendar.yahoo.com/?v=60&TITLE=Birthday&ST=20201231T193000&ET=20201231T223000&DESC=With%20clowns%20and%20stuff&in_loc=North%20Pole&inv_list=John+Doe+%3Cjohn@example.com%3E,Jane+Doe+%3Cjane@example.com%3E

Includes(Z): https://calendar.yahoo.com/?v=60&TITLE=Birthday&ST=20201231T193000Z&ET=20201231T223000Z&DESC=With%20clowns%20and%20stuff&in_loc=North%20Pole&inv_list=John+Doe+%3Cjohn@example.com%3E,Jane+Doe+%3Cjane@example.com%3E

[barinbritva]

For me link like this works: https://calendar.yahoo.com/?v=60&title=Event&st=20230418T190000Z&et=20230418T194400Z

It converts time zone to user's time zone. But you need to check you have set correct time zone in https://calendar.yahoo.com/setting
Yahoo (and Outlook) uses not time zone from browser, but time zone from user's settings

[alies-dev]

Still reproduces, and the cause is now known. Re-tested on 2026-08-19 from a browser in UTC+2:

https://calendar.yahoo.com/?v=60&TITLE=Test&ST=20261231T193000Z&ET=20261231T223000Z

The composer shows 19:30 to 22:30, not 20:30 to 23:30. So the Z is ignored rather than mishandled.

The reason is visible in the parser (qm in bundle_epoch_calendar.js). Every parameter that has no special case, ST and ET included, is stored with nothing more than

t[d] = decodeURIComponent(value.replace(/\+/g, " "))

There is no parsing of the timestamp and no timezone conversion at that point. The string travels to the composer as it arrived, and the composer renders it as a local wall clock time.

The Z suffix is read in exactly one place in the whole function, and only as a marker to copy onto a computed end time:

"Z" === t.startTime.slice(-1) && (t.endTime += "Z")

That branch only runs when DUR is used without ET. It never converts anything.

So this is not a rendering bug that a different input format can work around. Yahoo has no timezone parameter either (the parameter table has no entry for one), which means the only reliable approach today is to convert to the user's local time yourself and pass it without the Z suffix.

Both ST and ET now carry this warning in the documentation, see #61. Keeping this open as a real limitation of the service.