Cumulus Support

Edited the php file my log is here http://www.apeldoorn.tk/weer/realtimelog.txt I've stopped the ftp about more as an hor ago.

Weird, the log file looks fine, the first line looks to be in exactly the same format as the rest, I have no idea why the PHP script cannot interpret that date/time?
line 1, Fails - 25-11-12 17:46:18
line 2, Works - 25-11-12 17:47:08

mcrossley wrote:I have no idea why the PHP script cannot interpret that date/time?

Because the file has a BOM at the start?

On my local copy it says it's DOS/Windows UTF 8 ....

Does your software say whether it has a BOM or not? If it is Notepad++ the 'Encoding' menu item should tell you?

mcrossley wrote:Does your software say whether it has a BOM or not? If it is Notepad++ the 'Encoding' menu item should tell you?

Notepad++ says it's utf8 there is also UTF (without BOM) but thats not marked so i suspect it's UTF8 with BOM...

Updated the PHP to remove any BOM from the first field...

http://weather.wilmslowastro.com/realti ... p?view=sce

Apparently PHP will not understand BOM marked files until version 6

I have uploaded the file manually as utf without bom it seem te graphs are fine now, but my server is in the usa I thought the time was behind over there but its already monday

Oh lord, I hate time zone issues! If only all software stored and processed everything in a sensible way using UTC then we could just convert to locale time for display

If the server is in the USA, then I expect you will have to force it to use the Netherlands TZ, by adding in a line in the PHP before any date processing, I'd put it in around line 26.

Strange after adding the timezone it seems the BOM is back

nitrx wrote:Strange after adding the timezone it seems the BOM is back

The time is now 2 hours behind local time Europe/Amsterdam... interesting graphgs btw

And the dates created from the log file are an hour behind.

The script takes the date/time from the logfile, then
1. uses mktime() to create a date object in PHP, using your Europe/Amsterdam TZ
2. converts that to millisecs since 1970
3. send it to your browser
4. Javascript in your browser then converts that back to a date/time in the users TZ

So, I can see that your data will display on my browser an hour behind - the difference in TZ's
What is needed is for the PHP script to also supply the TZ so that Highcharts can calculate the correction for local TZ for the end user.
Not sure how to do this yet... (maybe just make it parameter in the script, but that may not work over DST changes )

Not sure about the BOM issue either, I will have to create a file with a BOM to test....

Both issues will have to wait until tomorrow now.

Oké very simple welk iets late over Here now, thanks for your efforts

Hi Ron

I have made a few changes this lunch time.

1. Dropped the RK 'tail' command for the GNU Windows port (http://unxutils.sourceforge.net/UnxUpdates.zip) as the Windows RK version doesn't seem to be able to count lines consistently!

2. Changed the RT log file creation batch to reflect new 'tail' and to do the initial copy in binary mode (text mode was appending a weird character at the end of the output file on my copy of XP )

3. Changed the PHP to not do any date handling at all - it's too hard with potentially the data coming from one TZ, the server in another TZ, and the end user in third TZ! Which leads to...

4. Changed the browser script to do all the date handling.

I also upped my time period to 2 hours so the data trends are better seen.

I suggest you download the new JS and PHP, the revised batch file is below... If you try it, let me know how it goes

Hi Mark,
great job but the tail command doesn't work I made the batchfile started tail.exe and after that the bat I get messages tail command not known and sleep not known.

Also tried to make it compatible with WinXP SP2 but no results unfortunally