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.
bobby
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:
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.
_______________________________________________
cosmo-dev mailing list
[EMAIL PROTECTED]
http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
