The political realities of timezones is _exactly why_ you should be storing the timezone name if the user is scheduling it for an event in their local timezone. If a user is expecting an event to happen at 6pm in their local timezone, and political reasons cause that timezone's offset to change (ie. daylight savings), it will still happen at the correct local time for that user.
Storing UTC offsets means that any future political changes will result in the wrong local times for users.
I suppose storing the offset is safer, because you have in a single string all you need to know to convert the time to UTC, but yes, that was my thought as well -- given a non-broken copy of tzdata, historical dates should be correctly convertible if all you have is a date/time and a timezone name.
True, but who cares? We're not talking about future dates, we're talking about recording a current timestamp, at which time we of course know the time zone and whether or not DST is in effect at that current point.
I think the main thing to remember is that dates and times have very different semantics when used for different purposes.
If you are referring to an instant in time, then just using UTC is reasonable. If you are referring to a past event and both the local time and precise instant are relevant, then the local time with a timezone offset is reasonable. If you are scheduling events on a calendar, however, like "8 AM every monday for the next four weeks", then yes, you need to store the abstract time zone name so that the calendar program can translate each instance of that schedule to the appropriate instant.
I wish they could at least store it in terms of the timezone name, like "Central Time". "America/Chicago" bothers me because I don't know what cities are and aren't in your timezone database.
The ones that have a tiny map that you have to click on are also pretty bad.
I think one of the reasons "Country/City" is used is due to variances within a timezone. Take Mountain Time, for example. "America/Denver" is different from "America/Phoenix" due to Arizona not observing daylight savings time. So in the middle of summer, America/Denver will translate to MDT while America/Phoenix will be MST.
(And I may be further proving your point if Denver isn't the landmark city, I'm just guessing!)
The reason for Country/City is because the timezone name is a global reference. It may be written in english, but everybody uses. Things like "pacific", "central" and "standard" mean very different things in other places.
Indeed, for many years the Eastern time zone in Australia was shortened to EST (Eastern Standard Time); just like the US Eastern time. With the wider advent of the Internet Australia renamed EST to AEST (Australian Eastern Standard Time).
The one in the Americas is the only one called "Central Time". It may not be the most politically correct name, but it happens to be the only name for it I know of, and it's the only timezone with that exact name worldwide.
Right, but very few people living in the continental US[0], when presented with a timezone dropdown, are going to expect to see anything but Eastern, Central, Mountain, or Pacific. If they do see a list that has city names, they'll be confused that their city isn't mentioned, or that they're expected to pick a city that's in their timezone but possibly geographically distant.
Personally, I (living in SF), use the "PST8PDT" named timezone; it just makes more sense to me than "America/Los Angeles", which is 400+ miles away from me (even though historically we've always had the same time as LA... as far as I know).
[0] Yes, there are a few places in the continental US that don't follow the "normal" 4 timezones and their DST schedules, so there are exceptions; specifically calling out those cities/locales is necessary, at least in those cases.
Sure, but the parent didn't say "CST". For a user-facing interface, presenting random city names is terrible. "Central Time" is a known entity among users, and they implicitly assume that it will take care of the difference between CST and CDT (and in fact, the named timezone CST6CDT does exactly that). Hell, if Chicago one day decided to be like a few of the "weird" US cities and not follow the standard DST schedule anymore, then "America/Chicago" would suddenly not represent most of the users in what's colloquially known as "Central Time". Better to use a name like "CST6CDT" that's independent of a particular city, and thus independent of the political whims of a local government.
A fair number of timezones don't have a name for the full timezone that implies those specific daylight savings rules. Maybe it'd work for there and they should call CST6CDT, "Central Time".
I'm not talking about people in your situation; I guess that wasn't clear. I'm talking about someone setting the time zone on their personal hardware. They know where they live and what their time zone is.
Besides, for your case there are easier methods, like Googling "current time in San Marcos, TX" (which Google will actually tell you the time and time zone without you needing to click on a results page; if you feel the need to, the first result has all the info you need as well). Hell, the "world clock" app on my phone tells me what I need to know when I enter in that city.
Storing UTC offsets means that any future political changes will result in the wrong local times for users.