AJAX and Dates

AJAX and Dates

While AJAX in general, and Data-Services in particular
becomes more and more in use, you may encounter a
problem of sending / receiving dates when you don't
usually share the same Time Zone settings.

Dates between services

When sending dates over soap the date is serialized
with the date and it's time zone
(The GMT +/- # part which comes straight after
the date itself).

When consuming a service through .Net application you won't notice
any difference, That's mainly because it  is being translated to your local time.
What's happens "behind the scene" is that the universal time is being sent
with the "Kind" property of "Utc", then it is being translated to your local time
according to your machine's time zone settings.

And what about your browser?

That's not exactly the situation when the service consumer is your browser.
On some browsers, when receiving dates through JSON, the date sometimes
keep it's original settings of date + time zone. displaying the hour with
date.format("HH:mm") can cause the hour not to be displayed according
to your time zone. I've encountered browsers of the same kind and version
that treat dates differently on different computers so you really cannot determine
what each browser will do.

How to determine what is the client treatments for dates?

Using the getTimezoneOffset() method of JavaScript date object
can be helpful, you can determine the client's time zone by using it
for a date created on client side, you can compare it with the server's
time zone in many ways : Sending the time-zone offset to the server
and compare the server's time zone there, You can send the time zone offset
along with the date from the server to the client and make your comparison
there. It is all depend on where the date object is in, posted date or response.

Just remember - the getTimezoneOffset returned in minutes and with the opposite
sign (meaning - date with Jerusalem standard time will return the result of -120).

What do you want to do with the date?

After you have this information you have to decide what you want to do with
it. If you want to display your dates according to your time zone,  determine what
your browser is doing by comparing the getTimezoneOffset() with the actual time zone
on the server. Then, you might want to set you date according to your policy by using
the setMinutes method .When deciding, you might take into account that on the client
side what you most of the time is displaying, and if you didn't use AJAX you would probably
display the dates according to the server's time zone.

Some Code examples in JavaScript

In here - the server sends the time zone offset inside the response (TimeZoneOffsetInMinutes):

var tzGap = resopnse.Date.getTimezoneOffset() * (-1) - response.TimeZoneOffsetInMinutes;

Note: What I did was actually changing the date, I cannot change the date's time zone offset
in JavaScript so the date in here is different from the date on the server.
Anyway - you have to omit time zone effect when sending the date to the server.

Summary:

Dealing with dates with web services was always tricky because of different time-zone settings.
It became evenmore tricky when the client is our browser (on AJAX) and we have to use some
good-old JavaScript tricks to overcome this issue. When sending dates from your client,
it's back to .Net code again and the date being sent is of "Utc" kind
(meaning that you can extract the client's time zone easily).
You can read about it in my "AJAX and DST difference" post.

New hours reporting system @ SRL

SRL, the company I work for, for the past two years, is saying goodbye to it's old hours reporting system.
The old system, which was developed long before I've started working there
and served SRL employees ever since, will continue serve SRL payroll staff
(untill  we move all management interfaces to the new system)but all other workers
are going to use the new one.
Usually this news it's not very exciting, not enough to write about, however
in this case, I was the one who developed it.

It has all started on my first week on the job. No Internet access at work
(It's alright I have one now) and non-windows OS at home has prevented
me from filling my hours report on this system which supports IE only.
A simple mail to my manager asking her to make a few adjustments in the system's
JavaScript to make it cross browser, has led me to complete replacement of the
hours reporting interface.

It took a great deal of studying new stuff for me, along with investigating the old system's
database and code. A great help in interface design and graphics from
my College Irena Chernov and receiving recommendations and remarks
from an endless list of colleges whom I've
recruited to the pilot team.

The development involved Lot's of AJAX, no Update panel, meaning that
the UI changes was almost solely on client side (Table created  on JavaScript after data
received from an AJAX enabled web service ), and a DAL adjusted to work with
the existing system's DB schema.

This has allowed as to have both old and new systems working
side by side so our payroll stuff can still work with their management
screens (that wasn't rewritten for the new system), along with employees
ability to enjoy a faster, cross browser and with some new features (Jewish
holidays built in the hours reporting table).

Needless to say that there were some problems along the way. Working
directly with clients outside our office raised DST setting difference
problem. The time needed to work on the system couldn't be on
working hours (because I work at a customer's site) which caused
the development process take much longer than expected, however
working on the new system was fun even so.

This is the opportunity to thank SRL staff for their trust,
Although the market is full with these kind of products and although these
kind of systems are considered  critical I was allowed to build one for SRL.
I want to thank all people who helped me along the way and to those who'll
suffer some bugs (hope not many and no critical ones).

And now for the next project...

Using Firebug extension

Before Visual Studio 2008 there wasn't many decent client debugging tools.
One of the tools that were already (and for free) was the Firebug extension 
for Firefox.

Firebug provides, among it's many features an in-browser script debugger
which consists some basic debugging features such as break points, step 
into functions, watches of local and global variables, automatic variables
and so on...

Script debugging

Like in VS-2008, you can actually debug your client scripts. the main difference is
that you can stay on the browser and not even have to open Visual Studio for
that meter. All you have to do is go to the script tab, click on the script
resource being debug (third tab on the top).
and reveal the list of scripts. Clicking the selected row will reveal the client
script produced there.


There clicking on a row will create a breakpoint, from there on - you can go with
the usual F10, F11 and F5 buttons we al familiar with...

Error counter

Moreover, one of it's best debugging features, provided also out of the  Firefox
Error-Console is the client error list.  It displays an error counter and provide
links to the relevant line by clicking on the specific error. 

Net transport

Like Fiddler tool, Firebug provides also a list of all page related requests with the raw data being
sent and received from the server. The difference between these two tools is that
Firebug provides only page-related requests, meaning that the list is being cleared on
every page replacement.
 

You can press the expand button (from this tab and from the console tab)and see headers, parameters or post data, and response:

Note: In order to see that response you'll have to press a button, that's because firebug didn't
want the performance penalty of processing each response on the browser and on firebug.

Client script profiling                                  

One of it's latest services is the script profiler, all you have to do is click "Profile" at the top and
click it once more to stop profiling. When you've first clicked, a console record is created and when
you've second clicked, the record is expanded to provide a profile report as seen in the picture below.
 

however, this tool is not perfect

JavaScript is many time a headache, using firebug won't  solve it, at least not completely
. Moreover, sometimes it will add it some headache of it's own. For example -
if you're using multiple tabs you will see sometime scripts from another tab.
Although a major performance improvement regarding performance, firebug is still a
debugging tool and therefore it slows your page loading process.

It's user interface is much less convenient that Visual Studio, for example the collapsible list
of the script resources to debug. It's DOM inspector and CSS editor are far less effective than
other tools available and so on...

In conclusion

Need a tool for script debugging, especially  if your targeted audience has multiple browsers
and you need your client script to be the closest you can to the standards? you may use
Firebug.
Need to review a web application client performances, need to track down errors easily -
Firebug may be your answer.
However, if you've developed an IE only application , Firebug may not worth the overhead
of making it standard.

On the other hand, it will suit you best if you're developing a web application that should
support almost all browsers (where it's better to develop for Firefox and test on other
browsers). It's is best for AJAX developers because of it's joined abilities of monitoring
your XHR transport and debug your script.