[Cosmo-dev] Re: [Design] Design] [Cosmo] Login-related workflows
br at osafoundation.org
Tue Nov 14 10:54:43 PST 2006
Your XDate stuff may be fine, but I think that there's little point
to rewriting or replacing the existing CosmoDate code when:
1) Most of the API is already compatible with the build in JS Date
2) CosmoDate was designed with the intention of popping in a better
timezone system when the time became ripe - now is that time, the
hooks are in place and it will be easy to do
3) The UI relies on CosmoDate already.
If there's any methods or functionality that you feel are missing
from CosmoDate that you need to add, by all means do so, but I don't
advocate pulling out the CosmoDate and replacing it.
On Nov 14, 2006, at 10:45 AM, Matthew Eernisse wrote:
> 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:
> 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 time.
>> As for rendering time, I assume the calendar events are returned
>> in UTC with an offset if a timezone is assigned.
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
More information about the Design