On Dates

times.markdown

If the users's time was 1970-01-01 and they were shown a page titled "tomorrows reservations", it would show no reservations.

However, this would be correct from the user's computer's perspective, just not from reality (unless maybe they are traveling at light speed).

In my opinion, despite the advantage of always showing reality, no matter what time the user has, it's better to use the client's local time for the following reasons:

• expectations
• accuracy
• performance
• flexibility
• long lived applications
• ease of development

Expectations

Currently, it's very common to present dates and times in desktop applications by the user's timezone. For example, chat and email clients use the user's time to display dates, not the server's that provided the message.

Accuracy

System clocks are set automatically by all modern operating systems making the likely-hood of incorrect times rather unlikely. Furthermore, if a user's time is set incorrectly, it will be obvious because every application will have an incorrect time and the application will return empty data.

Timezones

A day's data maybe different for Israel vs PST. If they pick a day, the data returned should use the user's local timezone.

It's possible to store the user's timezone on the server and provide that to the client, but it is more difficult to build. See ease of development.

Performance

The browser does not need to retrieve the server's time. This can be packaged with other requests, but that is not maintainable or reusable.

Flexible

I often configure my browsers to use different timezones for testing user experience in other timezones. I would have to create multiple accounts if the server houses this information.

Long Lived Apps

Often pages are long lived and users don't refresh the page. The server's data can become stale. For example, timestamps might need to update as time changes like in this example.

It is possible to update a the server's timestamps with estimates derived from the user's time, it is difficult.

Ease of development

It is far easier to develop with the user's time than the servers. Some use cases:

The user wants data for the last 4 hours:

Browser gets that date in users's time, converts it to UTC, and sends a request with the UNIX timestamp like:

var now = new Date(),
    time = new Date().getTime() - 1000*60*60*4
$.get("/data",{from: time, to: now });

The users want's Oct 20, 2011's data for their local time:

var time = new Date(2011,9,20).getTime()
$.get("/data",{"for": time });

The users want's Oct 20, 2011's data for UTC time:

var time = Date.UTC(2011,9,20).getTime()
$.get("/data",{"for": time });