Decide how to deal with far-off DST Transition points

[12wrigja]

Context: 20ef40ba6a0898fb477d16d198dbb1f2d50f00c4

When pulling in new commits from the proposal repo, I noticed that this commit's text mentions that it might be unsuitable for production code and so I skipped over it.

Though the current code is slow, maybe there are other ways to speed this up?

[ptomato]

I think this is best solved by moving away from the "bisection" method to find DST transition points - probably we'd need a source of time zone data other than Intl.DateTimeFormat. See tc39/proposal-temporal#1370 for an incomplete attempt at this.

[justingrant]

I don't think we should skip that commit, because the alternative is worse: an easy way to DoS a server that uses this API. Maybe extend to 5 years or 7 years? Real world time zone changes shouldn't occur further in advance than 5-7 years.

[justingrant]

And for a polyfill, I don't think we can get away with shipping the whole tzdb. Too big for browser use!