In this case progressive enhancement is offering a GMT date or other sensible default, and offer another date after javascript kicks in. Personaly, I think for

In this case progressive enhancement is offering a GMT date or other sensible default, and offer another date after javascript kicks in. Personaly, I think for anything where timezone is relevant, the best move is to always let the user manually enter the timezone he/she wants, or have it match the timezone of the event/service he's looking for, and of course allow for override, so changing timezone has to done client side. I.e. if I am in Germany and search from a flight taking off from Taipei two days from now, I don't care about the departure time from the German timezone. Same thing if I reserve a restaurant in Germany while I am in Taipei, you'll want the german time for the reservation. For something internationally broadcasted showing the UTC time as default and provide a way to adapt to other timezone is OK, as the event has no local anchoring anyway. People can do the calculation for timezones, eventually some opt to not change their phones timezone to keep in sync with other more important schedules, etc. Trying to do 'smart' things seamlessly is often just screwing with the user.