Jerry, when users input times, they need to know the timezone. If it is a personal calendar, then maybe a global config could 'assume until told otherwise' that the times are in the user's currently configured timezone. But as long as users are doing the input, they need to know the info, there is no way around that.
clock scan takes a subset of available timezones, I think, the pg data in ref-timezones seems even more limited. I know this because I picked timezone names off the internet and tried them with clock scan, and using them as input to pg.
Anyway, timezones only matter to the user, and only the inputing user knows if that data is correct, so having them create their own timezones, with offsets should be okay. All I'm talking about is a timezone name and offset, in seconds from GMT. Users could also have their own private timezone names. Instead of having to always remember PDT from PST, why not 'Pacific Winter', 'Pacific Summer', or 'My Company Home Office'? For online communities, it is important to consider that users might want to switch timezones on the displayed dates to make sure they know when events are happening in their local time, or East Coast time, or when it will be when they get to their destination in some other location.
Said another way: timezones provide context for an absolute time GMT. If users can switch the context at will, it is more likely they input data correctly, or update it later on, or just figure out what it means.
