Cumulus Support

FTP should be available now. Please reply to this thread with any problems.

Freddie, you're a star! Thank you VERY MUCH for sorting the ftp problem out.

My home page looks fine. The Data Summary page hasn't updated but I'm guessing that may be because data for 16/10/18 isn't present in dayfile.txt. I'll have to add that manually.

Is the server clear of malware?

RayProudfoot wrote:Is the server clear of malware?

I haven't seen any sign as yet - but there's a lot of looking to be done still.

Understood, thanks.

Freddie, I just noticed your banner time is showing GMT rather than BST. Not relevant to ftp of course but just wanted to point it out if it needs changing.

RayProudfoot wrote:Freddie, I just noticed your banner time is showing GMT rather than BST. Not relevant to ftp of course but just wanted to point it out if it needs changing.

Hi Ray, I keep all my systems (except desktops) on GMT. Saves problems with clock changes!
I noticed our temperatures were in synch earlier, but I'm colder now!
No sign as yet of malware!
.

Hi Freddie, you must be a pilot! They stick to GMT or UT wherever they are!

My garden is surrounded on 3 sides by houses so that keeps things a bit warmer. Cloud has come over too.

Fingers crossed on the malware front.

RayProudfoot wrote:Hi Freddie, you must be a pilot! They stick to GMT or UT wherever they are!

I have fingers in many pies, but I'm not a pilot! I just don't see the need for BST or any other form of daylight saving on servers. Good websites and client software will show dates and times using their local timezone. Also, for something like weather data where you have a fixed day start/end (relative to your local midday - i.e. when the sun is close to due south [or north, depending on your hemisphere]) then enforcing DST just complicates things.

freddie wrote:

RayProudfoot wrote:I just don't see the need for BST or any other form of daylight saving on servers. Good websites and client software will show dates and times using their local timezone.

It is 100% needed when using Mark's historic highchart graphs. Specifically, viewing solar and sunshine data plotted by the hour of the day. If timezone tables are not loaded then it can't fathom out if the clocks have gone forward or back (depending on what time of year you're viewing them) eg; showing sunshine between 9 and 10pm in the Summer, when it should be between 8 and 9pm. Same with sunshine in the Winter - showing sunshine between 7 and 8am when it should be between 8 and 9am. BST on the server solves that problem.

I agree that logging weather data using UTC and then converting for display is a good idea, it’s how Cumulus would have done it if I had been writing it as an application for use by others. When I had the luxury of starting again and not having to be compatible with Cumulus 1, it’s what I did with Cumulus 2. Perhaps when I hand MX over, someone could add it as an option

Mapantz wrote:

freddie wrote:

RayProudfoot wrote:I just don't see the need for BST or any other form of daylight saving on servers. Good websites and client software will show dates and times using their local timezone.

It is 100% needed when using Mark's historic highchart graphs. Specifically, viewing solar and sunshine data plotted by the hour of the day. If timezone tables are not loaded then it can't fathom out if the clocks have gone forward or back (depending on what time of year you're viewing them) eg; showing sunshine between 9 and 10pm in the Summer, when it should be between 8 and 9pm. Same with sunshine in the Winter - showing sunshine between 7 and 8am when it should be between 8 and 9am. BST on the server solves that problem.

It's a display issue, so should be catered for in the client/browser.

freddie wrote:It's a display issue, so should be catered for in the client/browser.

No it isn't. It requires timezone tables to be used in SQL.