Because your OPs and deployment team are going to know exactly how to deploy and support something you cobbled together in a completely arbitrary way.
You obviously thought through the integration with monitoring, scaling and multiple redundancy systems so in the event of traffic spike or disaster it'll keep working without manual intervention.
That's not even touching the business logic complexity of issues like DST or leap seconds where you have to be able to arbitrarily change the clock forward or backward.
Here ya go mate, caching, fallback, all in a 15 lines of javascript. If you want to extract jquery out of there that should be easy enough.
No need for extra servers, the OPs guys don't even need to know it's there. Take an extra performance hit that is equal to loading another image per page (yeah image requests, while probably served from CDN, also include an accurate Date response header as I checked), cached for 7 days (remove the cookie during periods of daylight saving times etc). Just have to make sure the server time is reasonably accurate. I'm sure a few seconds inaccuracy wouldn't matter.
Doesn't work if there's a proxy server caching old versions between the user and the server. Not to mention that according to the RFC standard intermediary servers are allowed to manipulate/remove/alter any non-restricted header (including Date).
Yes you can come up with a hacky solution that works 80% of the time quickly, but if you want a 99% solution you need to put the work in to do it right.
Actually, the Date content header is quite well defined in HTTP/1.1 [0], and should not be manipulated nilly-willy by intermediates. If you're having problems with proxies caching your requests, even if you're asking non-cached content [1], then you're never going to be able to get an accurate time from anywhere since any request might be cached, and no solution would work anyway.
It's not quite a "hacky" solution, I would guesstimate it would work 95% of the time rather than 80%, but even 80% is a great solution for the amount of work involved, the tradeoffs, and the fact that we're talking about a clock displayed on a website.
Or, you know, you could spend £15.000 taxpayers' money over 3 months for something I'm not even sure would be more flexible/maintainable/performant.
If you want that, you can just remove the caching, and it'll always accurately reflect the server time. However who changes their local clock? I think we could definitely get away with caching it for 7 days.
Same thing with DST (I even mentioned it). Also once you have an accurate time, the javascript time object includes the DST logic itself I think. We're only dealing with an inaccurate local clock, we don't have to reimplement whatever ISO standard stands for Time. As soon as we have the delta between local time and server time, we're golden.
Comments
Because your OPs and deployment team are going to know exactly how to deploy and support something you cobbled together in a completely arbitrary way.
You obviously thought through the integration with monitoring, scaling and multiple redundancy systems so in the event of traffic spike or disaster it'll keep working without manual intervention.
That's not even touching the business logic complexity of issues like DST or leap seconds where you have to be able to arbitrarily change the clock forward or backward.
Here ya go mate, caching, fallback, all in a 15 lines of javascript. If you want to extract jquery out of there that should be easy enough.
No need for extra servers, the OPs guys don't even need to know it's there. Take an extra performance hit that is equal to loading another image per page (yeah image requests, while probably served from CDN, also include an accurate Date response header as I checked), cached for 7 days (remove the cookie during periods of daylight saving times etc). Just have to make sure the server time is reasonably accurate. I'm sure a few seconds inaccuracy wouldn't matter.
Doesn't work if there's a proxy server caching old versions between the user and the server. Not to mention that according to the RFC standard intermediary servers are allowed to manipulate/remove/alter any non-restricted header (including Date).
Yes you can come up with a hacky solution that works 80% of the time quickly, but if you want a 99% solution you need to put the work in to do it right.
Actually, the Date content header is quite well defined in HTTP/1.1 [0], and should not be manipulated nilly-willy by intermediates. If you're having problems with proxies caching your requests, even if you're asking non-cached content [1], then you're never going to be able to get an accurate time from anywhere since any request might be cached, and no solution would work anyway.
It's not quite a "hacky" solution, I would guesstimate it would work 95% of the time rather than 80%, but even 80% is a great solution for the amount of work involved, the tradeoffs, and the fact that we're talking about a clock displayed on a website.
Or, you know, you could spend £15.000 taxpayers' money over 3 months for something I'm not even sure would be more flexible/maintainable/performant.
[0]: http://tools.ietf.org/html/rfc2616#section-14.18
[1]: E.g. URL's with random number in the query
Have you tested it over a daylight savings period or if the user changed their local clock?
If you want that, you can just remove the caching, and it'll always accurately reflect the server time. However who changes their local clock? I think we could definitely get away with caching it for 7 days.
Same thing with DST (I even mentioned it). Also once you have an accurate time, the javascript time object includes the DST logic itself I think. We're only dealing with an inaccurate local clock, we don't have to reimplement whatever ISO standard stands for Time. As soon as we have the delta between local time and server time, we're golden.