[Cosmo-dev] Re: [Design] Design] [Cosmo] Login-related workflows
mde at osafoundation.org
Tue Nov 14 10:45:58 PST 2006
Apologies for the cross-post, but this has turned into a code-related
discussion. How about we say any replies to this should be made over on
I guess I should have been a little clearer -- JS has nothing built-in
to let you do multiple timezones at once, or any other timezones than
the one that the local machine is set to. (The getTimezoneOffset method
only lets you refererence whatever timezone the local machine is set to.)
What we're working on is full timezone support for dates in JS, using
the Olson zoneinfo database (http://www.twinsun.com/tz/tz-link.htm).
This will mean that even out on the client we can get the correct GMT
offset for any arbitrary timezone, for any arbitrary date (including all
that fun daylight savings time stuff).
I have a first pass at a drop-in replacement for the JS Date object with
full timezone support here:
I would love feedback.
Jeremy Epstein wrote:
> You mean like this?
> var aDate = new Date().getTimezoneOffset()/60
> document.writeln(aDate )
> The *getTimezoneOffset* method returns an integer value representing the
> number of minutes between the time on the current machine and UTC.
> and yes, this implies adjusting for daylight savings time, what it
> cannot tell you is whether you are in daylight savings time, which may
> be what you are alluding to, but for the purposes of setting a default
> calendar offset (as opposed to entering times) this may be entirely
> appropriate, especially if any sizable portion of users work in floating
> As for rendering time, I assume the calendar events are returned in UTC
> with an offset if a timezone is assigned.
More information about the cosmo-dev