in-place Date replacement
Jan Niehusmann
after adding some jsunit tests and making sure they pass, I uploaded my
implementation of an in-place Date replacement.
It's meant to just overwrite the standard javascript Date constructor
with a custom, timezone-aware one. This should be transparent to all
applications and libraries using Date objects. Any application should
work as before, just using the specified default timezone instead of the
one inherited from the browser's locale.
As I made many changes to the code lately, it is not tested at all in a
larger scope, all I know is that the jsunit tests pass. I'll add more
test cases later, and also integrate the code into (at least) one
application, to see if it performs as expected.
The code is available from my branch tzdate on github:
http://github.com/jannic/timezone-js/tree/tzdate
Some documentation is included in the header of src/tzdate.js.
Jan
mde
This stuff looks great. One very high-level comment -- rather than
replacing the native JS Date object by default, giving people a
namespaced alternative (e.g., timezoneJS.Date) might be preferable, in
case there are applications where there are specific needs to preserve
native JS Dates for some reason.
If somebody really does want to use it as a wholesale replacement for
Date, it's super-simple for them to opt in themselves with a single
line of code that points Date = timezoneJS.Date.
Having worked on a complicated calendar app where we needed timezone-
enabled dates as well as fast, native JS Dates, giving people the
choice seems like a wise move.
I haven 't had a chance to review everything you've done yet, but if
it's more feature-complete, and more correct than the existing
timezoneJS.Date implementation, I'd like to adopt your approach in
place of what we have now.
What are your thoughts on this?
Matthew
Jan Niehusmann
I agree that it would be better to have the new functionality inside
some namespace, and only replace the Date object if the user really
wants it.
The difficult parts are getting the behaviour of the new object
identical to the original Date object. See the test cases in
test_dateStandardBehaviour: Libraries may do several things to test if
some object is a Date object, and all should work with the replacement
as well as with the native implementation.
First, I wasn't even sure if that was possible. Early attempts to add
these properties to fleegix.date.Date did fail miserably.
So I decided to just start from scratch and wrote the code which replaces
the Date object completely. After some experimentation, I managed to
fulfil the requirements I had. This is what lead to the current state of
tzdate.js.
I don't claim it's the best way to do it, and if it's possible to have
the new implementation confined inside some namespace and only override
the native implementation on request, that would be great. I'd consider
my current approach as a kind of benchmark: Any improvement should at
least preserve the currently available compatibility.
On Wed, Apr 07, 2010 at 01:18:25PM -0700, mde wrote:
> I haven 't had a chance to review everything you've done yet, but if
> it's more feature-complete, and more correct than the existing
> timezoneJS.Date implementation, I'd like to adopt your approach in
> place of what we have now.
It surely isn't more feature-complete. It only implements the same
featues as the original javascript Date, just with configurable time
zone. (And even that needs more testing, for sure.)
It's probably worth to try merging both implementations. Currently,
we have two implementations which do similar things. Both with some
unique features, so we can't just keep one and throw away the other
one. But in the end, maintaining both would just mean duplicating work
and making things confusing for the user.
Jan