Comment On Slowing Time

<script type="text/javascript">
var minutes = 1000*60;
var hours = minutes*60;
var days = hours*24;
var years = days*365;
var d = new Date();
var t = d.getTime();
var y = t/years;
document.write("It's been: " + y + " years since 1970/01/01!");
</script>

All too often we miss the built in functions.

Tempus fugit; time flies like an arrow, and fruit flies like bananas.

Next time, I'm going to skip reading the article so I can post frosttt. Also, this makes me wonder if what I'm doing with AJAX is ok.

Making as few calls to the server as possible is the name of the game.

Even updating that clock like that once a minute could be pushing it if there were enough users. Why on EARTH did they ever think making a server call every second for every user was a good idea? Especially with a lot of server-side logic for each call?

Sounds like an attempt to justify a hardware upgrade.

Remembers me of the gambling website for which I worked a while during college.

They used to take the local time via javascript and updated that every second. Since it was a gambling site they noticed that it would be better for the user to see the same time the server has (and the games were running with and so on). So they transferred the server time on page load and added one second each second.

What they didn't know was the fact that JavaScript is not running in real time. So after watching the screen for some minutes the clock was way off.

You don't want to know that kind of solutions were brought up during an emergency meeting. (One example: a small iframe that reloads every second with the server time that then via JavaScript gets distributed to the other frames...)

After some hours of arguing they took my simple solution: Transfer server time, compare with local time and every second set display to local time plus the difference between the both initial times.

The more tools the more abuse.

I've heard exactly the same thing about a thousand times before:

"<SomeLanguage> has a built-in <SomeUtility> object!?"

If only there was some sort of always-available resource of information that they could refer to in order to find out more about a given programming language. Like a kind of highway for information. It would be super.

What's needed is a built-in date function that hooks you up with Irish Girl.

Anonymous:

If only there was some sort of always-available resource of information that they could refer to in order to find out more about a given programming language. Like a kind of highway for information. It would be super.

Nah! It would take an act of Congress to get something like that done today.

Anonymous:

If only there was some sort of always-available resource of information that they could refer to in order to find out more about a given programming language. Like a kind of highway for information. It would be super.

Nah! It would take an act of Congress to get something like that done today.

Vollhorst:

Remembers me of the gambling website for which I worked a while during college.

After some hours of arguing they took my simple solution: Transfer server time, compare with local time and every second set display to local time plus the difference between the both initial times.

And just having system synch with a Time Server, and then just using local browser system time was too easy I guess.

> setInterval('updateClock()', 1000);

WTF? Shouldn't this be something like:
setTimeout('updateClock()', 1000); ?

Um, what the hell's this line?

she just cant get Enough ofmy MEET HYRDRANT --- 3nhanc3ment medz!!


...

Jim T:

Um, what the hell's this line?

she just cant get Enough ofmy MEET HYRDRANT --- 3nhanc3ment medz!!


...

think 'meat hydrant' - does that help?

This one always baffles me.
Why on Earth would anyone want to see a clock on a web page?!
One of the most useless things I can imagine...

The "Meet Hydrant" Subject is the best part of this story! HAHA!

Bosluis:

The "Meet Hydrant" Subject is the best part of this story! HAHA!

Yeah, I quite liked how that SPAM appeared in the list of messages he had in his inbox.

Juse:

> setInterval('updateClock()', 1000);

WTF? Shouldn't this be something like:
setTimeout('updateClock()', 1000); ?

Only if you want it to run once in 1000 milliseconds rather than once every 1000 milliseconds.

The real WTF is their crappy spam filter

Juse:

> setInterval('updateClock()', 1000);

WTF? Shouldn't this be something like:
setTimeout('updateClock()', 1000); ?

No.
Timeouts run once, intervals repeat.
EDIT: nevermind, you're right.

Dr. Who:

And just having system synch with a Time Server, and then just using local browser system time was too easy I guess.

Oh yeah, require some dinky gambling website to be allowed to change your system time to it's server's time zone. Wonderful idea.

eliac:

This one always baffles me.
Why on Earth would anyone want to see a clock on a web page?!
One of the most useless things I can imagine...

Very useful actually when you have multiple users distributed across various timezones who need to coordinate meetings or other activities.

brazzy:

Dr. Who:

And just having system synch with a Time Server, and then just using local browser system time was too easy I guess.

Oh yeah, require some dinky gambling website to be allowed to change your system time to it's server's time zone. Wonderful idea.

Um... no. There are plenty of time servers out there to which people can point their systems.

All the user's browser needs to know is the time zone of the server to adjust the time accordingly. As long as both server and desktop are synching on a semi-regular basis to the time server, they should be within a reasonably close accuracy.

Spamalot:

The real WTF is their crappy spam filter

No, the real WTF is that a change went in, and he wasn't already aware of it.

actually it should be

setInterval(function() { updateClock(); }, 1000);

Captcha: vereor

I would post a real comment, but I'm still waiting for the database to return your Locale, so I can personalize the comment for you.

Dr. Who:

Um... no. There are plenty of time servers out there to which people can point their systems.

If they have an NTP client and/or know how to install one and/or have the user permissions and ability to configure it.

All the user's browser needs to know is the time zone of the server to adjust the time accordingly. As long as both server and desktop are synching on a semi-regular basis to the time server, they should be within a reasonably close accuracy.

So basically the effect of your "too easy" solution is the same as Vollhorst's, except that his doesn't require the user to install or configure anything.

Why do people still insist on putting little clocks on their websites and programs? Everyone is *FREAKING SURROUNDED* by clocks! In your tray, on your phone, on your wrist, on the wall...

brazzy:

eliac:

This one always baffles me.
Why on Earth would anyone want to see a clock on a web page?!
One of the most useless things I can imagine...

Very useful actually when you have multiple users distributed across various timezones who need to coordinate meetings or other activities.

If I understand the article correctly, it was talking about displaying to the end-user his own local time. How does that help you to coordinate activities?

brazzy:

Dr. Who:

Um... no. There are plenty of time servers out there to which people can point their systems.

If they have an NTP client and/or know how to install one and/or have the user permissions and ability to configure it.[/quote/

Here are the instructions for Windows:

Microsoft:

To change the clock synchronization server
If your computer is a member of a domain, your computer clock is probably synchronized automatically by a network time server. If your computer is not a member of a domain, your computer's clock is automatically and regularly synchronized by an Internet time server. This procedure provides information about switching to a different Internet time server.

Open Date and Time in Control Panel.
Click the Internet Time tab.
The Internet Time tab is not available if your computer is a member of a domain.

Select the Automatically synchronize with an Internet time server check box.
In the Server list, click the arrow, and then click the time server you want to use.

All the user's browser needs to know is the time zone of the server to adjust the time accordingly. As long as both server and desktop are synching on a semi-regular basis to the time server, they should be within a reasonably close accuracy.

So basically the effect of your "too easy" solution is the same as Vollhorst's, except that his doesn't require the user to install or configure anything.

Not sure what universe you're speaking from.

No ntp client is needed to be installed, and on Windows is most likely already enabled.

And in my universe, a ONE-TIME-call to the server to tell the time zone of the server IS easy compared to a nearly constant update of the server's clock.

A man with one clock knows what time it is. A man with a watch, phone, tray clock, MP3 player, and cell is never sure.

Political Suicide:

Anonymous:

If only there was some sort of always-available resource of information that they could refer to in order to find out more about a given programming language. Like a kind of highway for information. It would be super.

Nah! It would take an act of Congress to get something like that done today.

To be fair, it took an act of Congress the first time around too.

brazzy:

eliac:

This one always baffles me.
Why on Earth would anyone want to see a clock on a web page?!
One of the most useless things I can imagine...

Very useful actually when you have multiple users distributed across various timezones who need to coordinate meetings or other activities.

And these users can't be asked to look at the time in their taskbar? Keep the clients in sync with net time, (s)ntp or whatever and no application will ever again need a clock. You can even automate this client side.....

RayMarron:

Why do people still insist on putting little clocks on their websites and programs? Everyone is *FREAKING SURROUNDED* by clocks! In your tray, on your phone, on your wrist, on the wall...

Matt Damon: On the bed, on the floor, on a towel by the door, in the tub, in the car, up against the mini-bar
Sarah Silverman: I’m f****** Matt Damon

eliac:

This one always baffles me.
Why on Earth would anyone want to see a clock on a web page?!
One of the most useless things I can imagine...

So the users know at a glance exactly how long they have left to work before they can go home?

Juse:

> setInterval('updateClock()', 1000);

WTF? Shouldn't this be something like:
setTimeout('updateClock()', 1000); ?

Here's The Real WTF(TM): setInterval creates a recurring timer: every call to updateClock creates another 1-second clock. So, the initial call to updateClock (from the onload attribute) creates the first timer. When that timer calls updateClock again, it creates another timer. One second later, both timers call updateClock, which creates 2 more timers, etc.

The number of calls to the server grows exponentially while the page is left open. This will not only bring the network to its knees, it will drag down the systems running this script, too.

Unless this is a problem with anonymization - if he didn't know about Date(), he probably didn't know about setInterval, either.

tom:

actually it should be

setInterval(function() { updateClock(); }, 1000);

Captcha: vereor

Or just:

setInterval(updateClock, 1000);

I agree, setTimeout and setInterval should be called with functions, not strings.

Capt. Obvious:

Political Suicide:

Nah! It would take an act of Congress to get something like that done today.

To be fair, it took an act of Congress the first time around too.

Perhaps my joke was a little too subtle.

brazzy:

All the user's browser needs to know is the time zone of the server to adjust the time accordingly. As long as both server and desktop are synching on a semi-regular basis to the time server, they should be within a reasonably close accuracy.

So basically the effect of your "too easy" solution is the same as Vollhorst's, except that his doesn't require the user to install or configure anything.

Yeeesss... except Volhorst's solution will be off by the network latency, and transmitting the timezine will show the proper time (provided that both computers are synced to a time server).

I would still go for the "transmit time and compare" feature though, because the network latency will usually be negligible (even a ~1s difference is probably acceptable), and the chances of stuff being configured improperly is non-negligible ;).

JavaScript has a built-in Date object!?

every time updateClock() is called it creates another interval
therefore:
first call 1 call (1 instance)
second - 2 calls (first instance and new one)
third - 4 calls

8 16 32 64 etc... etc...

[quote user="RiX0R"][quote user="brazzy"]
I would still go for the "transmit time and compare" feature though, because the network latency will usually be negligible (even a ~1s difference is probably acceptable), and the chances of stuff being configured improperly is non-negligible ;).[/quote]

As long as you own the accountability for sizing the infrastructure to support potentially thousands of these things - in addition to the rest of the workload. And provided that it is a potentially limitless budget.

In my experience, these things need to be brought to the attention of the management levels who have the accountability for the results of those decisions.

a browser has a build in scripting language ???

Brompot:

brazzy:

eliac:

This one always baffles me.
Why on Earth would anyone want to see a clock on a web page?!
One of the most useless things I can imagine...

Very useful actually when you have multiple users distributed across various timezones who need to coordinate meetings or other activities.

And these users can't be asked to look at the time in their taskbar? Keep the clients in sync with net time, (s)ntp or whatever and no application will ever again need a clock. You can even automate this client side.....

This is ridiculous suggestion, I would never sync my local machine with a different time zone. Can you imagine the problems it would cause for scheduled tasks? All of a sudden my computer is running a defrag pass and synching remote files because the clock is twelve hours out. Not a chance, the local clock must reflect local time always.

But it's still a dinky gambling website. Who would reconfigure their system based on instructions from some shady website? I sure wouldn't, and if you would, welcome to the wonderful world of botnets and spyware.

Heh, yep, if it's setInterval() they'll be adding more and more calls every second. Not only would it bring the server to its knees, the browser would be crippled in minutes.

I find that JavaScript in particular is a language that few people understand properly. It can be used simply to do a bit of web magic, which it usually is used for. It can also be used in all kinds of complex ways to do really neat stuff, which most people don't need and don't look at - and then are surprised when it does (or is capable of doing) something different than they expected.

Wait a second (no pun intended)... if this code was truly copied word for word, then it's far, far, worse than calling updateClock once per second... it's in a exponential recursive loop because each time updateClock is being called, it's asking updateClock to be called EVERY second, not just in the NEXT second. In other words, the developers may have caused a Gordon Freeman-like resonance cascade scenario with time. Scary stuff, indeed... never thought you could cause something like that with JavaScript, did you?

RayMarron:

Why do people still insist on putting little clocks on their websites and programs? Everyone is *FREAKING SURROUNDED* by clocks! In your tray, on your phone, on your wrist, on the wall...

You can never have too many clocks. From where I'm setting, I can see six of them (counting my watch).

Why yes, JavaScript does have time functions built in (sorry, viewable in IE only for the linked page): http://www.salemclock.com/extra/jclocks/cursorclock/cursor%20clock.htm

Maybe someone should point Barry to that page?

Anonymous:

Brompot:

brazzy:

eliac:

This one always baffles me.
Why on Earth would anyone want to see a clock on a web page?!
One of the most useless things I can imagine...

Very useful actually when you have multiple users distributed across various timezones who need to coordinate meetings or other activities.

And these users can't be asked to look at the time in their taskbar? Keep the clients in sync with net time, (s)ntp or whatever and no application will ever again need a clock. You can even automate this client side.....

This is ridiculous suggestion, I would never sync my local machine with a different time zone. Can you imagine the problems it would cause for scheduled tasks? All of a sudden my computer is running a defrag pass and synching remote files because the clock is twelve hours out. Not a chance, the local clock must reflect local time always.

NTP uses UTC, so it doesn't matter what time zone the server is in. Converting time zones should be handled by the application that actually displays the time, not by the system that actually keeps the time. Almost all modern operating systems do this except Windows. <rant>I hate that stupid dialog saying "Windows has updated your clock for Daylight Saving Time". It shouldn't have to update it! The clock on the taskbar should reference the current time in UTC with the timezone definition file, and adjust the display time itself, like xclock and every other Unix program that displays the time.</rant>