Yes, the key as Darius pointed out is that doing things the “right way” is surprisingly difficult, once you start thinking about the complexities.
The fundamental problem, I think, is that generally you want the client to do the “wrong” thing. That is, if the hospital/facility is in, say EST, you want to view and manipulate any dates/times related to that facility as in EST. You, in essence, want to “keep” the dates in EST… and out of the box javascript will fight you tooth and nail by trying to convert the date into the local time zone. If the server time zone equals the facility time zone, then you can try to achieve this the way I did–by stripping off the time zone component. But this will fail if the server time zone is not equal to the facility time zone. Taking a step further, if you ever have a single server for multiple sites in different time zones, you simply can’t have this.
Imagine this summary page:
Appointments scheduled for today:
Boston Clinic Tom Jones - 10:30am [edit time]
Kigali Clinic Mary Beth - 11:45am [edit time]
Obviously, this is a complex use case–viewing info from two facilities in different time zones on the same page, but worth thinking about when designing a solution.
@burke; interestingly, in the appointment scheduling module, we did take the header warning approach as a quick fix, and it was logged as an issue… see the responses on this thread…
I know that neither the simple header nor the stripping of time zones is ideal, but I thought that dropping the timezone might be an improvement, but maybe that is not the consensus opinion. 
Mark