Order Tray | Contact Us | Home | SIG Lists

[aprssig] Time stamps on FINDU pages?

Steve Dimse steve at dimse.com
Tue Apr 26 20:31:11 UTC 2005


On Apr 26, 2005, at 3:30 PM, Robert Bruninga wrote:

>> On the other hand, a click of a button or command-r is
>> less effort, and  yields data no more than a second or two old.
>
> No, it does not take seconds.  It takes MANY seconds on
> a dial up line and is extremely frustrating to have to do
> something as wasteful as refreshing an entire  100K byte
> page to get a few bits of information (date/time) that should
> have been on the page in the first place.
>
As usual, you are off exaggerating. NONE of my pages are anywhere close 
to 100k. The largest would be the ISS and PC Sat pages, which contain 
station lists as well as raw packets. the ariss.net page is 19,762, the 
b2v page which started this discussion is 13,523, and the find page for 
me is 5,391 bytes. On a poor connection at 28kbs or 3.5 kbytes/sec, 
which works out the less than 2 seconds for find, less than 4 seconds 
for b2v, and less than 6 seconds for the largest findU page. A 56k 
modem connection would nearly half those number.

Even if you were right and it took "MANY seconds" to refresh, that 
would not be a reason to change, I do not work on a lowest common 
denominator basis.

> Even then, without the time stamp, yes, I get a "refresh",
> but there is no proof anywhere on the page that it is
> really current, or if it is pure fiction...  Any data printed in
> any medium should have a date/time stamp or it is
> basically useless for any real analysis.

If you have that mentality, even with a timestamp there is no proof any 
of the data is real, findU could just be one big random number 
generator. If you want the raw data for analysis, all of those cgis do 
include the timestamps.
>
>> Mental gymnastics and old data, or a button click and
>> fresh data. To me  the choice is OBVIOUS!
>
> To me it is obviously wrong.
> 1) There is no mental gymnastics, HAMS can handle UTC.

I didn;t say they couldn;t, only that is takes longer than the second 
or 5 to do the math and then compare to your system clock.
>
> 2) "click and fresh" data is a missnomer for the information
>     age because the term "fresh" is totally ambiguous

Fresh data is not ambiguous at all. The B2V page is set to auto-refresh 
at one minute intervals. If there were a timestamp, you could figure 
out if the data is 5 seconds or 55 seconds old, and having done that, 
you now know the state of things 5 seconds or 55 seconds ago. But if 
you really care about the difference, then 99 times out of 100 what you 
really care about is the state of the system now, and a refresh gives 
you that. Far more useful than an old set of data and the knowledge of 
exactly how out of date it is.
>
> 3) presentation of time-relevant data keyed to real time, but
>     then without the time stamp of when that "time" was, is
>     completely ambiguouus the instant it is presented.

If you hit refresh, you know the timestamp. It is NOW. There is no 
ambiguity.

> No, I want to analyze the current data and so it is just silly
> that in this modern age, that I have to look at the clock,
> and write down on a  sheet of paper each time I hit the
> refresh key, to know what time the AGE data is based on!
> Computers are supposed to help us, not hinder us...

Bob, are  you really doing this with the B2V page? Please tell me about 
this analysis, I'd be fascinated.

If you ever needed to do any analysis of the findU data, I would use 
something like the raw, posit, or wx cgis, all of which give, either by 
default or through parameters, a timestamp for each report. What you 
seem not to realize is there are two separate classes of cgis in findU. 
One is meant to show things as they exist now, example of this is 
find.cgi. These are ephemeral, not meant for archive or analysis. The 
other is the archival ones, which show past data, example of this are 
wx, raw, and posit, these show old data and all have timestamps, which 
were added by me from the beginning, because there timestamps make 
sense.


>
> All I ask is to just put the UTC time at the top of the page,
> It is just one line of code and so valuable to the end user...
> I dont understand why you so adamantly resist this simple
> reasonable user request to time-stamp real-time pages.

For the simple reason that it clutters up the page design, forces more 
of the interesting data down below "the fold", and adds absolutely 
nothing to the presentation of the data. The only thing I would 
consider adding is a javascript clock that  kept counting the age of 
the data, for example, on the find page where it says last report "2 
minutes and 8 seconds ago". If someone produced a script that accepts 
the timestamp of the data, the timestamp of the page, and then grabs 
the system time when the page is loaded and displayed, I'd like to gave 
that time continue to count. I'm not sure such a thing is possible, I 
do not know javascript, but earlier in the thread someone mentioned it, 
and if it could be done it sould be cool to have it. But that is all I 
will consider...

Steve K4HG





More information about the aprssig mailing list