I'm working on a canvas graph that's updated in real time with information we're displaying to a customer, and were in the process of preparing for the DST change on the clocks. One of our requirements is for the graph to carry on functioning as usual without the need for the customer to refresh the page when the clocks switch over.

While working on this problem, I found out about this bug with Firefox:

Basically the Date() object in JavaScript doesn't update in Firefox if the system time is changed without having to close the browser/tab, and as we're querying an API using the system clock, this is a pretty major problem.

I'm assuming it's not fixed as the ticket is still marked as 'NEW', and I'm also pretty sure it's this that's causing the problem rather than another part of my code, so how can i get the current time of the system clock after it changes in Firefox without having to refresh the page?

Why would anyone of your customers change their system time? Mostly they are not allowed to change it. Is the specific page shown on every possible computer or on central workstations?
–
JoshuaMar 26 '13 at 9:53

Their system clock will change when the switch over to British Summer Time happens. As it's a real time graph, we need this changeover to happen fluidly on the users display.
–
Tom HalleyMar 26 '13 at 18:01

@TomHalley, can we assume that your customer's machine(s) will always be in either GMT or BST? Is this is the case, there's a really easy (though not very generic) solution..
–
NoyoMar 28 '13 at 22:10

Actually, @TomHalley, are you sure this isn't a problem with the way you're testing this? Have you tried changing both the time AND the zone? E.g., not just 12:00 -> 13:00, but 12:00 GMT -> 13:00 BST? An even more accurate simulation would be setting the clock to 2013-03-31 00:59:00 GMT, checking the hour, waiting a couple minutes, and then checking the hour again. There may not be an issue in your case -- please verify and report?
–
NoyoMar 28 '13 at 23:38

I can confirm the same behaviour on Linux. The timezone code in brackets is updated while the offset remains the same. So far this seems like the most practical client-only solution.
–
Andy EMar 27 '13 at 11:48

@AndyE As I was looking for better timezone data, I found out that different cities use the same abbreviation for different timezones. For example, Brisbane currently use EST +10:00 whereas EST in the US means -5:00. So unfortunately I cannot get this to work using the abbreviations alone.
–
AntonyMar 28 '13 at 13:00

@AndyE I have changed the answer to use web workers. Now this is a real workaround for the Firefox bug.
–
AntonyMar 28 '13 at 16:52

Nice work! I'm very impressed, though the only potential downside is the asynchronous nature of this approach, but still... great effort on your part :-)
–
Andy EMar 28 '13 at 17:18

@AndyE It turns out that the Date() function is updated whenever a new web worker is created. So we can simply call Date() without the onmessage event. This effectively removes the asynchronous requirement of the solution.
–
AntonyMar 29 '13 at 8:22

You can't ever rely on the client-side to have the correct date/time set anyway. The only workaround I can think of is to request the current time from another source, e.g. the server.

If you don't want to bug your own server you could find a public API that returns a timestamp, like some kind of Time API, or a service with reliable uptime such as eBay's Client Alerts API for instance:

I was considering this and hoping there was a solution that was client side, as changing the Date() usage to an API call would mean going through all of the code and changing all usages of Date().
–
Tom HalleyMar 22 '13 at 15:03

There is a simple (but very hacky) workaround for this problem. You can create a new window (which for some reason resets the cache of the current window), get the date from there, and then immediately close the window.

+1 for thinking outside the box, but I don't think this is a practical solution. When I tested this on Ubuntu, it only seemed to work once, although it worked even though Firefox blocked the popup. Subsequent attempts to fetch the date after changing the timezone didn't return the updated time zone.
–
Andy EMar 27 '13 at 11:41

To be honest, I didn't get that far because I still don't see it as a practical solution, even if it works :-)
–
Andy EMar 27 '13 at 15:08

It may be possible to ask the user to enable popups. For example, if their app already uses popups for other reasons. Alternatively, there may be ways to circumvent the popup blocker. The OP stressed a client-only solution, and these drawbacks may be worth it.
–
Sergiu ToarcaMar 27 '13 at 15:19

As you are talking about real-time updates of the canvas I assume that you are using some kind of push technology, such as making use of web sockets, or some fake push technology such as AJAX long polling.

However, as you can not rely on the client-side time anyway (as was mentioned in the other answer), why not just use your real-time push data packages to include the current time?

This way you can kill two birds with one stone (sorry for the martial expression, but that's how they say ;-)):

You have one central clock you can rely on: Your server.

You make use of your existing data update infrastructure and do not need something else on top.

Clients can set their clocks to whatever they want, they will always the correct data.

All your clients need to do is to get the timezone they are in initially, and then add or subtract the difference to the timezone that is being delivered by the server. E.g., if your client is on UTC+1 and your server is UTC+4, then simply subtract 3 hours from each timestamp your server delivers.

As DST changes only appear twice a year, you can even hard-code this into your client and use two different addition / subtraction algorithms. Which one you have to use you can decide depending on the date part of the time stamp the server sends to you.

This way you should have solved all your problems, it works in every browser, and is independent of any time settings of the client.

// the referenced bug keeps the same time, but it successfully changes the time zone, so:
var currentDisplayHour = getDisplayHour( new Date() ); // returns 13

Tested on FF 19.0.0.2 on Mac and Windows 7.

Note: Since I wasn't really able to reproduce the OP's issue, and considering the cited use case, I'm not even sure there's a need for any of these workarounds at all. One might expect a more accurate test for the OP's use case to involve changing both the time AND the zone. E.g. not just 12:00 -> 13:00, but 12:00 GMT -> 13:00 BST. An even more accurate simulation of the DST changeover would be to set the clock to 2013-03-31 00:59:00 GMT, check the new Date().getHours(), wait a couple minutes, and then to check the hour again.

But, as I said, I haven't been able to reproduce the cited bug this myself, so I could definitely be wrong (in which case I'll amend or remove this answer).