Primenet web design

[James Heinrich]

Originally Posted by Madpoo

I even toyed with using some Javascript to have an updated time on the page but that mostly depends on visitors having their own clock and timezone set correctly, so I abandoned that.

An alternate approach is to feed the browser the correct UTC time on pageload, then just increment the time every second. Undoubtedly the time will drift from absolutely correct over time (and, in fact, will be off by page-load time right from the start), but should be generally "correct enough" for the amount of time a page is likely to remain open, and more reliably correct than depending on the user's computer to have an accurate clock/timezone.

[Madpoo]

Originally Posted by James Heinrich

An alternate approach is to feed the browser the correct UTC time on pageload, then just increment the time every second. Undoubtedly the time will drift from absolutely correct over time (and, in fact, will be off by page-load time right from the start), but should be generally "correct enough" for the amount of time a page is likely to remain open, and more reliably correct than depending on the user's computer to have an accurate clock/timezone.

I think people who need it should just have this link always handy:
http://www.timeanddate.com/worldcloc...en.html?n=1440

The websites I work on are spread across 21 different countries and something like 12 timezones... that website is great since you can build a custom URL that shows your current time plus the local time in a bunch of other cities.

[chalsall]

Originally Posted by Madpoo

Thanks darling... or is it "sir"?

Darling is fine....

[James Heinrich]

Originally Posted by James Heinrich

An alternate approach is to feed the browser the correct UTC time on pageload, then just increment the time every second.

Just for fun I tried it out. You need to wrap an ID'd <span> around the actual date string so you can update that string, and then this unnecessarily-complicated chunk of code will increment it. Unless I missed something it seems overly complex (compared to what I would do in PHP) since there is no formatted output you need to construct the date format element-by-element, and then ugly things like getUTCMonth() returns 0-11 rather than 1-12, and all the getUTC____ functions return integers so you need to worry about zero-padding them. But it works.

<div>Current time: <span id="current_utc_time">2014-10-13 19:57:55 UTC</span><span style="font-size:8pt;"> - Page rendered in 0.0426s</span></div>
<script type="text/javascript">
	function incrementUTCtimestamp() {
		var current_time = new Date(document.getElementById('current_utc_time').innerText);
		var updated_time = new Date(current_time.getTime() + 1000);
		var Y = updated_time.getUTCFullYear();
		var M = updated_time.getUTCMonth() + 1; // getUTCMonth return 0-11
		var D = updated_time.getUTCDate();
		var h = updated_time.getUTCHours();
		var m = updated_time.getUTCMinutes();
		var s = updated_time.getUTCSeconds();
		M = ((M < 10) ? '0' : '') + M; // add zero-padding where needed
		D = ((D < 10) ? '0' : '') + D; // add zero-padding where needed
		h = ((h < 10) ? '0' : '') + h; // add zero-padding where needed
		m = ((m < 10) ? '0' : '') + m; // add zero-padding where needed
		s = ((s < 10) ? '0' : '') + s; // add zero-padding where needed
		document.getElementById('current_utc_time').innerText = Y + '-' + M + '-' + D + ' ' + h + ':' + m + ':' + s + ' UTC';
		setTimeout(incrementUTCtimestamp, 1000);
	}
	setTimeout(incrementUTCtimestamp, 1000);
</script>

With minimal modification you could set the timeout to 60000 and omit the seconds from the datestring if you prefer.

[cuBerBruce]

What I really care about is the UTC when the data was generated. If the hourly reports all display that specially, then having the footer include the UTC of the time the page was downloaded is fine. I would not want to have the value updated in real time to try to indicate the current time.

Another little point: I don't care about how long it took to render the page. I am guessing that is useful to Madpoo while working on these changes, but it seems to me that it's unnecessary information for the typical user.

[flagrantflowers]

http://www.mersenne.org/assignments/...et+Assignments

Doesn't sort by percentage. It separates the data into two sets: tests which have been started and tests which have not been started.

[Madpoo]

Originally Posted by cuBerBruce

Another little point: I don't care about how long it took to render the page. I am guessing that is useful to Madpoo while working on these changes, but it seems to me that it's unnecessary information for the typical user.

I actually don't care either. It was there from the old pages and I just kept it around.

It may have provided more insight on the old server if a SQL query was taking a long time to return data. There are currently a few custom reports that pull some SQL backend stuff that take a while, but all in all having that on the page isn't terribly useful most of the time.

But all in all, it's in the footer and I shrunk the size of it so I guess it's harmless enough.

[Madpoo]

Originally Posted by flagrantflowers

http://www.mersenne.org/assignments/...et+Assignments

Doesn't sort by percentage. It separates the data into two sets: tests which have been started and tests which have not been started.

Technically that column is treated as text, and even then it tends to sort poorly. The tablesorter plugin will also, by default, sort empty data last. There are some options to have empty stuff sort differently but in this case it wouldn't really matter.

To have it sort by the actual % progress, I'd have to look at how that data is generated and remove the text in front of it. I'm not sure why but it only seems to add "LL," for the LL tests, not double-checks. I'm going to assume there was a reason though.

I think the sorting gets confused if there's a mix of #'s and text... I might just be able to force that column to sort only by text and see if that's any better.

EDIT: Oh, I get why it shows "LL" for example. It's showing the stage + the % done of that stage. LL assignments might have to do factoring first so it might show that % progress. That's not likely to happen now that the GPU's are racing ahead with factoring, far ahead of any LL ranges, but I guess it could still happen.

And speaking of GPU72... once all exponents below 1E9 are TF'd will the project get a name change to GPU73 and go back to make sure everything is factored at least that high (increasing the TF depth one bit all along the way)? Kidding... I think...

[potonono]

Notice: Undefined variable: etacolor in C:\inetpub\www\assignments\default.php on line 126
Notice: Undefined variable: etacolor in C:\inetpub\www\assignments\default.php on line 130

[legendarymudkip]

Originally Posted by Madpoo

And speaking of GPU72... once all exponents below 1E9 are TF'd will the project get a name change to GPU73 and go back to make sure everything is factored at least that high (increasing the TF depth one bit all along the way)?

I think we'll be waiting a while to factor all exponents to 2⁷².
Especially those < 1M

[James Heinrich]

Originally Posted by Madpoo

..will the project get a name change to GPU73 and go back to make sure everything is factored at least that high (increasing the TF depth one bit all along the way)?

By the time you get up to ~4000M the target TF (according to the current rules, which will undoubtedly be obsolete by then) is 2⁹² (and TF'ing one exponent to that level is ~125THz-days )