• Chris Judge (unregistered)

    Every time updateClock is called, it spawns a new interval without killing the old one.

    So at the end of the first visit, there are two intervals. One second later, both of these call updateClock and each one creates a new interval (now there are four). At the end of one second, all four call updateClock and each one creates a new interval (now there are 8). Etc.

    Here's an example that shows what happens:

    <html>
      <head>
        <title>timer test</title>
        <script type="text/javascript" language="javascript">
          var intervalCount;
          var timerCount;
    
          function initialize() {
            intervalCount = 0;
            timerCount = 0;
            startTime = Date();
    
            setInterval('updateInterval()', 1000);
    
            setTimeout('updateTimeout()', 1000);
          }
    
          function updateInterval() {
            intervalCount++;
    
            document.getElementById("txtIntervalTime").value = Date() - startTime;
            document.getElementById("txtIntervalCount").value = intervalCount;
            
            setInterval('updateInterval()', 1000);
          }
    
          function updateTimeout() {
            timerCount++;
    
            document.getElementById("txtTimeoutTime").value = Date() - startTime;
            document.getElementById("txtTimeoutCount").value = timerCount;
    
            setTimeout('updateTimeout()', 1000);
          }
        </script>
      </head>
      <body onload="initialize();">
        Elapsed time according to updateInterval(): <input id="txtIntervalTime" type="text" /> seconds.
    updateInterval has been called: <input id="txtIntervalCount" type="text" /> times.
    Elapsed time according to updateTimeout(): <input id="txtTimeoutTime" type="text" /> seconds.
    updateTimeout been called: <input id="txtTimeoutCount" type="text" /> times.
    </body> </html>
  • Mr.'; Drop Database -- (unregistered)
    Comment held for moderation.
  • Luis Espinal (unregistered)

    This is sad, sad, but true.

    It does betray a lack of foresight and understanding. For one thing, what major programming language today lacks a mechanism for getting the current date and time?

    Second, what sort of programmer would think a major programming language lacks one? What could one possibly think to not even just f* google for it?

    Also, what sort of programmer would not think "uhmmm, what would happen to this little piece of database-calling thingie during peak hours"?

    A good friend of mine calls this "happy programming" - programming for the happy case. It worked on my computer, it gotta work on freaking production, too!!!

  • ura more on (unregistered) in reply to Chris Judge
    Chris Judge:
    Every time updateClock is called, it spawns a new interval without killing the old one.

    So at the end of the first visit, there are two intervals. One second later, both of these call updateClock and each one creates a new interval (now there are four). At the end of one second, all four call updateClock and each one creates a new interval (now there are 8). Etc.

    Here's an example that shows what happens:

    [...snipterriblyretardedexamplesnip...
    uranidiot. functionalexamplenotwithstanding.
  • SAMO(c) (unregistered)

    But who was david's phone?

  • prrof reed (unregistered)

    Jake, can please proof read the article you submit it you submit it.

  • DataGhost (unregistered)
    "I'm not a web developer," David asked, "but why didn't you use JavaScript's built-in Date object?"
    People like David are what's slowing down innovation. I'm sure everyone remembers Web 1.0, where we had websites with the current time on them... using the Javascript built-in Date object! Using AJAX is the only logical Web 2.0-alternative. Performance really is a server-side issue, so they should upgrade those instead.
  • sysadminwhohastoadminspamassassin (unregistered) in reply to Spamalot

    Only one spam in his inbox, that is actually pretty good.

  • Ima Great guy (unregistered) in reply to DonkeyRyan
    DonkeyRyan:
    All too often we miss the built in functions.

    Sure, funny, haw haw. Except that there are some problems with the JS date object, most notable being that it uses local computer system time rather than anything "trusted", so it's only as accurate as the system clock.

    If you've ever tried to rely on the system clock, you'll quickly know just what a bad idea that this is.

  • jmz (unregistered) in reply to RayMarron

    Because time is money of course. The more clocks you have, the more time you have, the more time you have, the more money you have. So clocks==money. Don't you get it?

  • javabeats (unregistered) in reply to Anonymous
    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.

    You don't travel very much, do you?

  • Pony Princess (unregistered) in reply to Knux2
    Knux2:
    Why on EARTH did they ever think making a server call every second for every user was a good idea?

    did they ever think making a server ever think think

    You found the problem!

  • immibis (unregistered)

    There's that issue you mentioned in the post...and then there's the issue that setInterval calls do repeat until the page is closed... So the first updateClock sets a timer to call updateClock every second. Fine. The second updateClock sets a timer to call updateClock every second. So now it is being called twice a second. Every second it doubles. It's a wonder their computers didn't crash first.

  • Matt (unregistered)

    I'm only an amateur coder as a hobby, but once I was working on a homebrew project where I needed to get the time from the server.

    All I did was get the server time during page load and then use that as a starting point for javascript to start incrementing the time. The update was only called once per page load which seemed to do the job.

    If people are getting paid to code like this then there may be hope for me yet! ;)

  • noway! (unregistered)

    How about having a javascipt that gets the time from a NTP server once a second?

  • Adam Jorgensen (unregistered)

    Yes, JS has a Date object.

    No, you shouldn't use it.

    Not when such a delicious extension to it called DateJS exists...

  • You didn't see me right (unregistered) in reply to GameCrash
    GameCrash:
    Maurits:
    Zapp Brannigan:
    Jay:
    I think it's totally inappropriate to treat your Date like an Object.
    Should a date be treated like property?
    Like a member.

    You could always treat your Date like an Interface...

    I certainly like to Interface with Dates. Shame they never let me at their private members.

  • (cs) in reply to jmz
    jmz:
    Because time is money of course. The more clocks you have, the more time you have, the more time you have, the more money you have. So clocks==money. Don't you get it?

    Time is money, to get a Date, one needs time and money -> Date = Time*Money -> Date=money^2

    Now, money is the root of all evil: root(evil) = money, money^2 = evil, Date=evil...

    Somehow I doubt Dates are worth the time...

  • John (unregistered) in reply to jspenguin
    jspenguin:
    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>

    Another manifestation of this problem occurs when using 'rsync' for backups. I backup gigabytes of data on a Windows system every day. Apart from the initial backup, it completed in minutes until the daylight saving changeover.

    Then, because the timestamp of all files on the Windows system changed, rsync took hours to complete a backup that had taken a few minutes the day before.

  • (cs) in reply to An Onymous
    An Onymous:
    ZaM:

    Shouldn't that be something like "TM you must FR"?

    I thought Yoda always started with the verb and put adjectives after the noun (French style).

    That would be "R you must TMF"

  • InitHello (unregistered) in reply to ITIL Genius
    ITIL Genius:
    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.

    Not only was he unaware of it, but he should have also known what kind of impact it would have on performance. He should be reprimanded.

  • eliac (unregistered) in reply to steenbergh
    steenbergh:
    jmz:
    Because time is money of course. The more clocks you have, the more time you have, the more time you have, the more money you have. So clocks==money. Don't you get it?

    Time is money, to get a Date, one needs time and money -> Date = Time*Money -> Date=money^2

    Now, money is the root of all evil: root(evil) = money, money^2 = evil, Date=evil...

    Somehow I doubt Dates are worth the time...

    Strangely, multiplication and addition are two different things. So: to get a Date, one needs time and money -> Date = Time + Money
  • Dave (unregistered) in reply to John
    John:
    I backup gigabytes of data on a Windows system every day. Apart from the initial backup, it completed in minutes until the daylight saving changeover.

    Then, because the timestamp of all files on the Windows system changed, rsync took hours to complete a backup that had taken a few minutes the day before.

    TRWTF is using a professional strength tool like rsync on a toy like Windows.

    No, TRWTF is having gigabytes of data on Windows.

    No, TRWTF is Windows.

    C'mon, people, we keep giving you examples like this that Windows is chock full of insane fundamental design errors that haven't been fixed in decades and still you keep dragging out excuses that it will be better next year. Get a clue already and give up! There's no hope for this clunker! There never will be.

  • FatherStorm (unregistered) in reply to Anonymous
    Anonymous:
    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.
    And that's why in my innocent Treo/pre-Android years I lived by "Sprint Time"
  • Popeye (unregistered) in reply to Dave

    Except the Mutli billion dollar company I work for uses it.

    We all know that bad things get better with time, just like fine wine or cheap beer.

    dignissim - make a dignissim one way or the other.

  • Zygo (unregistered) in reply to ITIL Genius
    ITIL Genius:
    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.

    I'm aware of changes made to the local source repository in real time, 24 hours a day, 7 days a week.

    If I'm looking at that window, which is on a screen physically located in the office.

    And if I drill down under the summary data, which looks like this:

    09:57:21 <SVN> tokoe:  Renamed KContactManager to KAddressBook
    09:57:22 <SVN> tokoe:  Add missing file
    09:57:24 <SVN> trueg:  * Handle Resource::resourceUri in toUrlList. This allows to convert QUrl, QList<QUrl>, Resource, and QList<Resource> into a QList<QUrl>
    09:57:27 <SVN> trueg:  Support annotation of files through their pimo thing. The annotations of thing and file will be combined.
    09:57:31 <SVN> vkrause:  oops, we missed a const here
    09:57:33 <SVN> vkrause:  fix handling of invalid cache entries, fix memory leak, cleanup job
    09:57:35 <SVN> jriddell:  hal-cups-utils is gone
    09:57:37 <SVN> tokoe:  Remove dbus interface dependency

    Despite raising the issue in every single weekly meeting, we still aren't getting developers to write "created severe performance problem on Intranet web server" in their commit logs, even though they do write things like "fixed severe performance problem on Intranet web server caused by commit 1005231."

  • Zygo (unregistered) in reply to RayMarron
    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...

    ...and they're all WRONG, except for the ones that are slaved to an atomic clock somewhere on the network. Heck, my cell phone has a dialog under "Settings" which says things like "Obtain time from <carrier network>" and "Network time is <correct current local time>", but the cell phone's clock is still wrong by at least 3 minutes.

  • Zygo (unregistered) in reply to eliac
    eliac:
    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?

    The first version displayed the server's local time (unless they jumped through hoops to convert to the client's time zone). That way, when your geographically sparse workforce needs to coordinate meetings in multiple time zones through your web calendar application, they can just look at part of the web page to figure out what time it is now, in the tiny little mind of the calendar app. Everyone uses the same time zone, whatever it is, and does the conversion themselves to figure out when the meeting really is.

    The second version displayed the user's local time (unless they jumped through hoops to convert to the server's time zone). That way, it's no better (and possibly actually worse) than the clock in the user's system tray. The geographically sparse workforce will never have meetings at the same time ever again, unless the length of the meeting in hours is equal to or larger than the number of time zones between the eastmost and westmost attendee.

  • Jay (unregistered) in reply to Zygo
    Zygo:
    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...

    Too many clocks?! That's like saying, "Too many Irish girls". The individual words are real words, but when you string them together in that order, it just doesn't make a coherent sentence.

    ...and they're all WRONG, except for the ones that are slaved to an atomic clock somewhere on the network. Heck, my cell phone has a dialog under "Settings" which says things like "Obtain time from <carrier network>" and "Network time is <correct current local time>", but the cell phone's clock is still wrong by at least 3 minutes.

    Just what are you doing that having a clock that is off by a minute or two causes you irreparable harm? Do you really have your schedule planned that precisely? Oh no, I had planned to go to lunch at 12:13 but here it is 12:15 and I haven't gone yet!

  • Zygo (unregistered) in reply to Dr. Who
    Dr. Who:
    No ntp client is needed to be installed, and on Windows is most likely already enabled.

    The strange thing about the NTP client built into Windows is that it always seems to end up settling on a time a few hundred milliseconds before or after every other NTP client I've been able to test, then drifts all over the place, occasionally applying a half-second step forward or backward to get back in line. It's like Windows doesn't even try to maintain accurate time.

    Contrast with Linux systems on the same LAN that maintain their clocks within the same millisecond with each other, and a dozen ms or so over WAN links.

    It's been a few years since I've had any Windows systems to test with, but we set up an NTP server hierarchy on both Windows and Linux, and any client that had a choice (Windows clients always pick their domain master) always picked the Linux servers for their more stable time.

  • Zygo (unregistered) in reply to RiX0R
    RiX0R:
    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).

    and provided that both computers have up-to-date time zone data. Legislators like moving the transition dates around every few years...

  • Zygo (unregistered) in reply to Anonymous
    Anonymous:
    emptyset:
    I suppose nobody liked THE CLOCK THAT CAME WITH THEIR OS.
    You mean the clock that came with their motherboard. The O/S has no built-in time keeping ability of its own. Sorry, pedantry!

    The clock on the motherboard is a cheap, slow, inaccurate piece of crap. There's dozens of RTC chips in the field. The lowest common denominator of these devices can only return accurate time once per second, and requires quite long CPU-driven signalling sequences (a millisecond here, a millisecond there, pretty soon your server is crawling under this load). "Accurate" here is a relative term, since some of these clocks drift by minutes per day. They're actually so bad that most operating systems reset the motherboard clock from the OS-maintained clock every few minutes--without that adjustment, the motherboard time would be off by most of an hour within a week or two.

    Modern systems have cycle counters built into the CPU as well as programmable interrupt timers. The lowest common denominator of these devices has a precision of dozens of nanoseconds and can return accurate time directly from a CPU register. "Accurate" here is still pretty bad by clock standards but it's orders of magnitude better than the motherboard clock. The real win is the precision, because it can be used with an NTP server to calculate what the CPU clock rate actually is.

    Even Windows, which has arguably the most primitive time keeping of any of the non-embedded modern operating systems, still has the ability to measure its local time sources (PIC and CPU cycle counters) against reference time sources (NTP servers with data from atomic clocks) and adjust the OS-maintained time keeping.

    For example, the OS might program your PIC to give an interrupt every 1000us, then after several hours of tracking NTP servers the OS may discover the PIC interrupt comes every 999.962us. Once this is known, the OS can simply increment the system time by 999.962us every PIC interrupt, and keep time accurate to seconds per month even if the network clock goes away.

  • (cs) in reply to Dave
    Dave:
    Get a clue already and give up! There's no hope for this clunker! There never will be.
    Depends on what you hope for. It's earned me a damned comfortable living for the past 13 years.
  • Zygo (unregistered) in reply to John P Goodman
    John P Goodman:
    For all those who say "just configure the client with NTP", you apparently have never had a rogue time server take out an entire Windows domain's authentication because Someone Thought It Was A Good Idea To Keep The Client Clocks In Sync With The Faulty Government Time Server*... clock skew is a bitch.

    That's why you configure your NTP server to use at least 4 upstream NTP servers operated by different organizations, at least one of which should be a local GPS receiver or your own atomic clock if your organization is large enough to own one. That way, one broken server will be voted down by all the others (though you should have an alert configured so that when it happens, you choose a new 4th upstream server to replace the one with the incompetent admin).

    Your clients, of course, should speak only to your own NTP servers.

  • Paul N (unregistered) in reply to Brompot
    Brompot:
    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.....

    Try pressing F11 and see if you can still see the time in your taskbar.

  • Paul N (unregistered) in reply to iToad
    iToad:
    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).

    Sounds like overclocking to me.
  • John (unregistered) in reply to Dave
    Dave:
    John:
    I backup gigabytes of data on a Windows system every day. Apart from the initial backup, it completed in minutes until the daylight saving changeover.

    Then, because the timestamp of all files on the Windows system changed, rsync took hours to complete a backup that had taken a few minutes the day before.

    TRWTF is using a professional strength tool like rsync on a toy like Windows.

    No, TRWTF is having gigabytes of data on Windows.

    No, TRWTF is Windows.

    C'mon, people, we keep giving you examples like this that Windows is chock full of insane fundamental design errors that haven't been fixed in decades and still you keep dragging out excuses that it will be better next year. Get a clue already and give up! There's no hope for this clunker! There never will be.

    My data is generated in a Unix-like environment but transferred to Windows because, well, that's what everyone else uses.

    I'm a little tired of being considered weird and subversive because I prefer to process my data with non-Windows tools.

    Tired, too, of explaining to colleagues that Word is not my text editor of choice. That, although all the data I process has to end up on Windows machines, Windows hinders rather than helps me.

    I've been told I'm not allowed to complain about Windows any more.

    I try not to, but the phrase "blinkered philistine pig-ignorance" comes to mind several times a day.

  • Zygo (unregistered) in reply to Jay
    Jay:
    ...and they're all WRONG, except for the ones that are slaved to an atomic clock somewhere on the network. Heck, my cell phone has a dialog under "Settings" which says things like "Obtain time from <carrier network>" and "Network time is <correct current local time>", but the cell phone's clock is still wrong by at least 3 minutes.

    Just what are you doing that having a clock that is off by a minute or two causes you irreparable harm? Do you really have your schedule planned that precisely? Oh no, I had planned to go to lunch at 12:13 but here it is 12:15 and I haven't gone yet!

    Yes, actually. Don't you? How else do you know when you're on time? How do you catch a bus, or turn on a radio or TV at the right time to catch a scheduled broadcast? How do you know your alibi is confirmed by security camera footage? If you set other clocks using your clock of questionable accuracy, how do you know you're not compounding errors? A minute or two can cause irreparable harm to a steak on a BBQ. A clock that can be off by a minute or two can be off by 20 minutes, or 2 hours. How would you know?

    Yes, I can do whatever I need to do one minute earlier, but then I'd have to know (or guess) the time on my clock is a minute slow. What if my clock is actually two minutes slow? Or ten? Is waiting a total of an hour a day for slow clocks OK, but 70 minutes is too much? Or is 50 too much? What if I make a decision about someone else based on a clock that is fast, making me falsely believe they are late?

    Generally I disable the time display feature entirely on any device with a clock that can't get its time from a network, and thereby minimize the number of clocks I have to maintain. The few that are left, e.g. the one in my stove, can detect and report failure to maintain accurate time, e.g. by blinking "12:00". Others, like the occasional mechanical clock or watch that is unable to detect that it loses an hour or two a day, I learn to ignore, because sooner or later they will tell me the wrong time (though they are useful for timing steaks on the BBQ, as long as I only use one clock for the entire cooking process).

    Anyway, the size of the error doesn't matter if it's big enough to display. Whether it's 3 minutes or 30, my point about the cell phone is that if you're going to claim network time sync as a feature, and there is a difference between cell phone time and network time greater than one minute, or if the difference cannot be measured because the network is unavailable, or the error in the measurement is greater than one minute, I should be seeing some kind of error notification so that I know the clock might be wrong...otherwise, you might as well not bother putting that feature in the firmware, and use the space saved for more ringtones.

  • Escape (unregistered)

    What I don't get, is why they had to do

    url = url + '?employee_id=' + <?=$employeeID;?>;

    and getting the timezone from the DB, when they could use, say... sessions, avoiding DB connection and queries?

  • (cs) in reply to Paul N
    Paul N:
    Brompot:
    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.....

    Try pressing F11 and see if you can still see the time in your taskbar.

    Yes. Yes, I can. Admittedly I have to move the mouse down to the lower edge of the screen to see it, but I'd have to do that even without pressing F11 if I had the taskbar set to auto-hide. I don't think it's a big problem.

  • Herby (unregistered)

    A man with one clock knows the time. A man with more than one clock isn't sure. Those who have their clocks sync'd with a standard are sure.

    Me? I have a wall clock (a nice Radio Shack one, thank you) that gets its information from WWVB. The clocks on my computer automagically sync via NTP. Why do I worry about this? For me, having "second accurate" time is nice when you are doing EBAY stuff. Their clocks are nicely sync'd to some nice NTP server and that makes my clocks in sync with them. It is quite nice.

    Than there is windows. It isn't that accurate AT ALL. I had to find an NTP update program to get it to display the time correctly. Even then, it doesn't display seconds, a major bummer if you are trying to land a last second bid.

    Then I look at the guide on my satellite TV provider. It is always a bit off, probably due to the round trip time to the satellite!

    Time is such fun!

  • Another Anonymous (unregistered) in reply to Anonymous

    Tray Clock can sync to a timeserver, the MP3 player can sync to the computer, the phone can sync to a timeserver on the cellular network.

    All my clocks are set to the same time +- 2 seconds.

  • (cs) in reply to Anonymous
    Anonymous:
    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.

    Awesome - astutely put...!

  • Geoff (unregistered) in reply to RayMarron

    It's a bit like that.. although since my wristwatch died I haven't missed it. Either the PC, my phone, or the clock in the car will tell me what I need to know. I'm seldom away from all 3.

  • jordan shoes (unregistered)
    Comment held for moderation.
  • Here's a nickel, kid... (unregistered) in reply to Code Dependent
    Code Dependent:
    Dave:
    Get a clue already and give up! There's no hope for this clunker! There never will be.
    Depends on what you hope for. It's earned me a damned comfortable living for the past 13 years.
    Yep. Job security. That's why we went for DOS way back when...
  • Here's a nickel, kid... (unregistered) in reply to Zygo
    Zygo:
    Dr. Who:
    No ntp client is needed to be installed, and on Windows is most likely already enabled.

    The strange thing about the NTP client built into Windows is that it always seems to end up settling on a time a few hundred milliseconds before or after every other NTP client I've been able to test, then drifts all over the place, occasionally applying a half-second step forward or backward to get back in line. It's like Windows doesn't even try to maintain accurate time.

    Contrast with Linux systems on the same LAN that maintain their clocks within the same millisecond with each other, and a dozen ms or so over WAN links.

    It's been a few years since I've had any Windows systems to test with, but we set up an NTP server hierarchy on both Windows and Linux, and any client that had a choice (Windows clients always pick their domain master) always picked the Linux servers for their more stable time.

    You're exactly right. I remember reading it in the spec a few years back...the windows utility is designed for only 1/2 sec accuracy. I was fairly surprised when I found that out, but figured, it's just a pc, big deal. Then the PHB decided we didn't need no stinkin' ntpd, let's cut that complex stuff out of the mix. And of course, for most purposes, no biggie. But, PHB's responsibility included bastion firewalls, etc...still couldn't get him to see the value of good time for forensics.

    Couldn't stand him, left. Eventually company couldn't stand him either.

  • (cs) in reply to emptyset
    emptyset:
    I suppose nobody liked THE CLOCK THAT CAME WITH THEIR OS.

    The honking big Vista desktop clock that immediately gets covered by windows? Why would anyone hate that?

  • Vic Tim (unregistered)

    i have a date function

    it's very limited to "before foo" and "after bar"

    but I can sort events like nobody's business

  • John Muller (unregistered)

    So, one day I was looking for tileset making software, for a console style RPG; gog'd 'tile making software' and went to a promising result, turned out it was a ceramic tile company, but there was something odd...

    they showed the date like "March 10th, 19107"

    I laughed a bit, as it had only been 7 years since the whole Y2K thing ended the world.

    followed the link to their web design company, that also showed the year as 19107..., as discussed their combined 120 years of web design exp, etc. etc.

    it worked fine in IE, showing '2007' but not firefox...

    I can't fathom how they ever got 19107...

    (1900)+(107) numerically gives 2007... if it were erroniously treated as a string "1900" + "107" should have given "1900107"...

    My simple solution, Don't show the time. Why bother, when there are so many other clocks around, to add a feature that might go wrong?

Leave a comment on “Slowing Time”

Log In or post as a guest

Replying to comment #:

« Return to Article