It'd still be an issue, because people lose their minds when thinking about time zones. Example: .net XML serialization. The PM wanted to "do the right thing" and thus would encode all dates in XML with an offset determined by looking at some local setting. Hence the exact same code would produce a different XML document depending on the selected time zone.
They 'fixed' it by using a couple bits of the date to note if it was UTC or 'local'. But for a version or two, there was no way around corrupting data. The PM lamented the fact, saying "if only machines all had GPS, then we'd know the right offset to use", further demonstrating the lack of understanding.
Some folks just can't resist thinking in local time, instead of letting the dev handle time zones additionally.
Even the great tzinfo database is weird. Instead of using the names of time zones, it uses a random city. Which means if a time zone does split up in the future, you might end up with an incorrect timezone. (Like if I select Denver, but Denver switches to New Mountain Time, but my city doesn't.)
I'm sure there's no problem that can't be created by a sufficiently bad PM.
I think you can treat the name of the city as the name of the timezone. Seems like you'd have the same problem either way. If you used "Mountain Time" and then your city switches to "New Mountain Time" you still have the incorrect timezone.
Instead of cities it could use polygons on the surface of the earth, but that's starting to get complicated at that point.
