Time zone names

@chroma, on the watch or elsewhere?

@user140377, the problem is an actual timezone map is going to be O(megabytes), and while there are only ~600 reference locations (so using only tens of k you could practically present the user with a list ordered by [N/S biased] distance), I'm not sure where we can get their lat/lon other than trawling the IANA database manually—Java, for example, has chosen to strip it out.

It turns out there's another problem: if you use setTimeZone it's possible to fake temporal objects in other timezones in userland (by subtracting the time zone offsets and then adjusting the underlying ms time by this amount, so that interactions with the time and date fields behave as expected), but you have to do all DST calculations yourself (and possibly break other code's expectations). To the contrary, if you use setDST it will get the calculations right automatically for the main zone, but it becomes impossible to manipulate times in other timezones no matter how hard you try, because there are now 60 (usually) unnamable minutes in every year!

I've been trying to think of a way to address this other than to have a second kind of Date—one that's bound internally to a setDST packet—but I haven't had enough coffee yet.