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

[Matthew Eernisse]

See below ...

Bobby Rullo wrote:
> 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

Sounds good. There's actually very little code overlap between the 
current XDate and current CosmoDate beyond the getter methods. It's 
mostly just stuff that's missing.

In fact, CosmoDate is mostly a bag of attributes (with getters) at this 
point -- and a few methods, some of which just pass off to our 
add/diff/strftime, some of which are convenience (after/before), and 
some which we might not need if we could instantiate just like a normal 
JS Date (e.g., updateFromUTC)

How we get there is way less important to me than where we end up. I 
just want to minimize work, and maximize benefit to us. So here are a 
few of the things banging around in my head about this:

1. We want to get our timezone-capable Date replacement into Dojo, so 
others can use it, we aren't maintaining it by ourselves, and we get 
bugfix support from the community (it's also good press for OSAF).
3. Dojo is highly unlikely to implement something called 'CosmoDate.' I 
don't think anyone there is religious about the name, but 'Cosmo' ... ? :)
2. Adding in real timezone support is already a fairly large project, 
and it would be nice only to have to make the large change to all the 
code one time, rather than once now, and once after our code moves into 
Dojo.

Again, I don't care what we call this date thingie -- the only reason I 
advocate a name change now is that it saves me work in the UI code later 
down the road. We're already jacking up CosmoDate, so now would be a 
good time for a large change like this.

As for the functionality, there's very little overlap, so it's just 
filling in the gaps. All those getter methods are exactly the same. My 
suspicion is too that some of the Cosmo-specific methods will involve 
some rewriting for real timezone support anyway (e.g., 
strftimeLocalTimezone).

Basically, I just want to be able to use a timezone-aware date just like 
a normal JavaScript Date -- which would mean adding all the setter 
methods, and fixing the constructor method so that it doesn't just 
blindly set property values from the params passed in.

(Also it would sure be nice just to call dojo.date.add and pass it one 
of these dates instead of having a special static method call directly 
on our date object. And a pony.)

I also really like the idea of having a separate Date-only data-type, 
but some folks might think it's not necessary. It just seems to give 
server-side guys more options, and doesn't really add that much 
cognitive overhead.

Thoughts?


Matthew