Pat's new .py file seems to fix some of the charts. But, I think not all.
I'm gathering details and will send them to him to check and see if there
is still an issue to address. I'll post what I find here.
phil
On Saturday, September 29, 2018 at 9:47:24 PM UTC-4, Pat wrote:
>
> Hi everyone, I th
Hi everyone, I think this has been resolved in a latest commit. In 0.6 I
was using timespan but also highcharts was packaged as 1 skin. The
timespans were giving me some problems, so I reverted to time.time and that
was causing the problems you see. Thanks Gary for taking the time to check
my c
Yes, same for me. The week.json datafile has the last point for each
measurement associated with the beginning of the 60 minute period following
the current time. So, it is the same cause. As you say, it's likely related
to the timestamp Pat chose to use.
Phil
On Tuesday, September 25, 2018 at
I've just noticed that the end of the Week chart is an hour ahead of my
current time - probably all related
On Wed, Sep 26, 2018 at 7:40 AM Colin Larsen wrote:
> Thanks Gary and Phil for finding and sorting this :)
>
> On Wed, 26 Sep 2018, 04:19 Philip Kutzenco, wrote:
>
>> Gary,
>>
>> Excellen
Thanks Gary and Phil for finding and sorting this :)
On Wed, 26 Sep 2018, 04:19 Philip Kutzenco, wrote:
> Gary,
>
> Excellent. Thanks for sussing this out! I'll look forward to Pat's next
> release.
>
> Phil
>
> On Tuesday, September 25, 2018 at 10:04:07 AM UTC-4, gjr80 wrote:
>>
>> OK, I think
Gary,
Excellent. Thanks for sussing this out! I'll look forward to Pat's next
release.
Phil
On Tuesday, September 25, 2018 at 10:04:07 AM UTC-4, gjr80 wrote:
>
> OK, I think I have handle on what is happening here. The cause is as Phil
> has noted, the last timestamp in each data series in mon
OK, I think I have handle on what is happening here. The cause is as Phil
has noted, the last timestamp in each data series in month.json is midnight
at the end of the current local day. A commit by Pat on 4 September changed
that timestamp from being the last timestamp in the archive to being t
So, looking at the data in the json file, the last epoch date in the series
is 153793440 and translates to September 26 at 4:00 AM UTC. So that is
midnight on September 26 EDT (my time zone). So it sounds like the
aggregated temperature data displayed is for the period prior to that
date/ti
I can concur with the error, timezone here is NZ Standard Time (+12)
Have a look at my Monthly graph - sorry can't get a screen grab with the
cursor in place to show that the graphs are ahead of time. Maybe it's
forecasting :)
http://41south.net.nz/graphs/
Colin
On Tue, Sep 25, 2018 at 3:34 PM
I suspect the issue will be related to how highcharts is interpreting
timestamps in the plot data rather then the wrong data being in the plot data
files. I have seen something like this before but it was related to the
timezone of the client computer viewing the plots, would seem that is not th
OK. More info. I checked Pat O'Brien's website and also Juan Antonio
Mosquera's website. Neither shows the date offset that my website shows.
So, It looks like I've got a problem with my implementation or my database.
But, since the NOAA reports for monthly min and max seem to be correct,
that
Ah, yes. Gary is correct. It appears that only rainfall is aggregated (two
hour aggregates for the Monthly plot). The others seem to be Min or Max at
a discrete time.
Phil
On Monday, September 24, 2018 at 10:19:34 PM UTC-4, Philip Kutzenco wrote:
>
> Thomas,
>
> I think you are correct about ag
Not saying what is right or wrong but the rain data provided by the
highcharts extension is an aggregate sum over an hour or a day, depending
on the time period of the plot. That may be why rain is behaving
differently to other obs.
Gary
On Tuesday, 25 September 2018 11:19:10 UTC+10, Thomas Ke
You're probably right. Plus, I gather that you are working with aggregated
plots, not the raw data?
It was just a thought...
-tk
On Mon, Sep 24, 2018 at 6:11 PM Philip Kutzenco wrote:
> If that's so, wouldn't rainfall also exhibit the offset?
>
> Even if Thomas is correct (and something about
If that's so, wouldn't rainfall also exhibit the offset?
Even if Thomas is correct (and something about rainfall calculation keeps
it from being offset), the call out numbers (showing data values and date)
you see when you move the cursor across the graph are wrong because of the
date offset. S
In WeeWX, records are timestamped with the *end* of the record. Perhaps
Highcharts uses the beginning?
-tk
On Mon, Sep 24, 2018 at 10:28 AM Philip Kutzenco wrote:
> I notice that, for me, some of the historic data graphs supplied with the
> Belchertown skin are off by one day. In particular, if
I notice that, for me, some of the historic data graphs supplied with the
Belchertown skin are off by one day. In particular, if you go to the
"Graphs" page and select either "Month" or "Year", the temperature graph
data are labeled as being one day beyond what they should be. For instance
at t
17 matches
Mail list logo
