I don't have a real answer to this question, but as a software engineer who works with data feeds from all over the world, a standard of 24 static time zones would be the best thing to happen since the perpetual calendar. The measurement of time is one of those elusive concepts that everybody thinks they understand until they have to actually deal with it. I have heard honest-to-goodness shouting matches between seasoned developers over how to interpret and implement time arithmetic.

Don't get me wrong. The current implementation of time zones is way better than a total lack thereof, as was the case prior to their invention. At least there is some means by which times and dates may be compared to one another around the world. Before that, my understanding (not that I've done a ton of research) is that every town or municipality had its own measure of time based on strictly local observations and concerns. That turned out to be a complete nightmare for any entity that had to conduct business across cities and countries in a timely fashion.

However, the current time zone implementation is fraught with problems and basically can't scale. To implement time tracking and arithmetic as a computational model, you end up with so many little quirks and exceptions that the scope of such a project blows way, way out of proportion to anyone's initial assumptions. In fact, talking about time with software engineers is a great way to address issues of hubris, hidden assumptions and poor estimation by way of analogy.

I'm on my phone and don't have it handy, but some developer wrote a really great blog post about time zone implementations a while back. I kind of hope that someone here remembers it and posts a link so that I can bookmark it again. The author addresses the myriad concerns about time zones at length, with great humor and wit. It's easily one of the trickiest concepts to deal with in the practice of software engineering.