[Cosmo-dev] Re: [Design] Design] [Cosmo] Login-related workflows update

[Matthew Eernisse]

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 
cosmo-dev?

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:

http://www.fleegix.org/demo/xdate.html

I would love feedback.

Thanks!


Matthew


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 
> time.
> 
> As for rendering time, I assume the calendar events are returned in UTC 
> with an offset if a timezone is assigned.
> 
> 
> Jeremy.