Look into timezone optimizations

The current timezone implementation is fairly slow (took around 120ms to take an VTIMEZONE for PST and process it on my MBP).

We touched on this but I think its going to be really valuable to pre-build the timezone objects as its own JS file and then we can loaded it as needed. We can then improve the existing logic for determining the UTC offset by to increase / decrease the year coverage.

I think they may also be value to (at built time) determine which years related to which "changes" for example PST daylight savings start in March and then standard resumes in November so we have 3 set of "changes" to go through vs every change of all time (86) per year. These performance gains may be minimal but I suspect when the rules are more complicated there could be major savings here.

Start by profiling the current timezone implementation, especially processing a VTIMEZONE for PST, to confirm where the reported 120ms is spent. Then evaluate pre-built timezone objects, lazy loading, and narrower year/change lookup coverage. Done means the optimization approach is defined and demonstrates measurable gains without losing timezone correctness.

Written by the indexing model from the issue text.