Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Comment Re:How about GMT? (Score 1) 545

The UK isn't on Zulu time - they have daylight savings time (don't know about Portugal and W. Africa).

DST in the EU starts on the last Sunday of March and ends on the last Sunday of October, so for Portugal it's:

$ TZ=Europe/Lisbon date -d "Oct 27 00:59:59 UTC 2013"
Sun Oct 27 01:59:59 WEST 2013
$ TZ=Europe/Lisbon date -d "Oct 27 01:00:00 UTC 2013"
Sun Oct 27 01:00:00 WET 2013

I don't know the DST rules for the various countries in West Africa, but (shameless plug) tzdata-javascript.org has a demo where you can compare the time in two different timezones.

Submission + - Dice Ruins Slashdot (slashdot.org) 12

An anonymous reader writes: In an attempt to modernize Slashdot, Dice has removed everything that made Slashdot unique and worthwhile and has turned it into a generic blog site. User feedback has been unanimously negative, but this is to no avail, and users will have to head elsewhere for insightful and entertaining commentary on tech news.

Submission + - Change.org petition, ARM SoC changes for Linux 3.12 invite Torvalds' fury (paritynews.com) 1

hypnosec writes: Linus Torvalds, in response to a petition on Change.org to remove RdRand from /dev/random, has lambasted the petitioner by called him ignorant for not understanding the code in Linux Kernel. Kyle Condon from UK raised a petition on Change.org to get Linus to remove RdRand from /dev/random in a bid “to improve the overall security of the linux kernel.” In his response, Torvalds asked the Condon and the supports of the petition to gain an understanding of Linux drivers, cryptography and then "come back here and admit to the world that you were wrong." Torvalds stressed that kernel maintainers knew what they were doing and the petitioner didn’t. Torvalds, in a similar outburst just yesterday, hoped that "ARM SoC hardware designers all die in some incredibly painful accident." This came in response to a message from Kevin Hilman when he noted that there were quite a few conflicts in the ARM SoC pull request for Linux 3.12, which were a result of the platform changes conflicting with driver changes going in to the V4L tree.

Submission + - How to foil NSA sabotage: use a dead man's switch (theguardian.com) 4

mspohr writes: Cory Doctorow has an interesting idea published in todays Guardian on how to approach the problem of NSA "gag orders" which prevent web sites, etc. from telling anyone that they have been compromised. His idea is to set up a "dead man" switch where a site would publish a statement that "We have not been contacted by the government" ... until, of course, they were contacted and compromised. The statement would then disappear since it would no longer be true.
He points out a few problems... Not making the statement could be considered a violation of disclosure... but, can the government force you to lie and state that you haven't been contacted when you actually have?

Comment Re:Really? Why not just query the NSA directly? (Score 1) 97

Why would you limit yourself to ssh, when there's so many useful unpatched exploits for so many other server applications? Among other things, you're missing out on all the easily exploitable Windows ME boxen out there.

ssh defaults to port 22. Port 23 is usually telnet.

Comment Re:User's time, not BBC time (Score 1) 487

1) Clock drift in excess of a minute per day is not unheard-of.

I don't think I have ever seen numbers that high myself, but if needed, the time_diff could be recalculated more often. If the page notice a large clock drift between two calculations of the diff, it could schedule the next recalculation to occur sooner.

2) If the AJAX request fails, what do you do?

For the first calculation of the diff, you don't really need to use AJAX since the page already includes the server time in the "clock"-element. If a later AJAX-request fails, you could simply reuse the old diff and schedule a new calculation at a much sooner time that otherwise.

3) If the AJAX request hits a high asymmetric delay (not unheard-of), you'll be off by a good fraction of a minute.

You're right, I don't have a good solution for that problem. Maybe take a look at how NTP deals with it.

4) If the user can't set their computer's clock, what makes you think they can set the computer's timezone?

I don't think I said anything about the user setting the timezone anywhere, so I fail to see your point.

I did mention the "Europe/London"-timezone, but that timezone would be set by the BBC site, not the user.

5) Related to 4, what happens during a daylight savings time shift? You can't count on the local clock changing by an hour, but you also can't count on it *not* changing.

What daylight savings time? There's a reason why I'm using milliseconds since Epoch.

If you know the time in milliseconds since Epoch and you know when the transition between standard time and daylight savings occur (or any other change of offset from UTC), you can calculate the local time. You can find the transition times and offsets in the tzdatabase and do the calculation yourself or you can use the tzdata-javascript library I mentioned.

Comment Re:User's time, not BBC time (Score 2) 487

What the BBC said was that they would find it difficult and expensive to accurately show the time at the user's location, when the user's time settings were wrong.

This is roughly how I would do it:

  • Make sure the server is running NTP or something similar, so the server time is correct.
  • When the page is requested, include the current server time: <span id="clock">Thu Jun 6 11:29:04 BST 2013</span>.
  • If JavaScript is off, we can't update the time and all we can do is display that static time.
  • If JavaScript is on, we:
    • Find the HTML-element: var clock=document.getElementById("clock");
    • Get the current local time as milliseconds since Epoch: var local_time_1=new Date().valueOf();
    • Use AJAX to get the current server time as milliseconds since Epoch, server_time.
    • Get the current local time as milliseconds since Epoch, local_time_2.
    • Assuming that the delay from the client to the server is the same as the delay from the server to the client, calculate the difference between server time (correct time) and local time: var time_diff=server_time - (local_time_1+local_time_2)/2;
    • Every second, minute, whatever...
      • Get the current local time as milliseconds since Epoch, local_time.
      • Calculate the assumed server time: var assumed_time=local_time + time_diff;
      • Update the HTML-element to display the assumed_time in some "pretty" format.
      • If you don't want to display the time in either UTC or "whatever timezone the user has configured", use something like (shameless plug) tzdata-javascript to convert it "Europe/London".
    • Maybe recalculate time_diff every hour to avoid time drifting. I highly doubt this is needed.

Wouldn't that work?

Comment Re:nt (Score 0) 128

Who the American Idol winner is has no real effect on my life, whereas my local city council does when they decide whether to put money into repairing nearby streets or changing the zoning to accommodate a CVS in my neighborhood.

Your local council decides that? Weird...

When I wanted to have a version control system, I just installed one. I didn't have to get permission from anyone.

Slashdot Top Deals

The key elements in human thinking are not numbers but labels of fuzzy sets. -- L. Zadeh

Working...