More or less. Even more simply, think of WeeWX (and python) as using timestamps the ‘units’ of which are seconds since epoch. V4.5.0 introduced a new ‘unit’ of time in the report space that is milliseconds since epoch. When the report space wants to deal with any other part of WeeWX (and python) it needs to speak in seconds since epoch. Before that v4.5.0 that was implicit as there was only one unit of time, post v4.5.0 it needs to be explicit.
Gary On Tuesday, 13 April 2021 at 15:28:25 UTC+10 [email protected] wrote: > i am using https://github.com/chaunceygardiner/weewx-forecast v.b12, > which, as you say, calls almanac > > i think i understand. deep in weewx (call it weewx ‘kernel’), monotonic > time is a fundamental always measured in time_t. in the upper levels of > weewx, in the world of weewx units, time is an observable property with > transformable units. almanac is really part of the ‘kernel’, which works in > time_t only, so any time values from the units space must be converted to > time_t before being presented to almanac i.e. it is actually a bug in > forecast, in this case [and might imply some tweaking needed in the almanac > interface within cheetah] > > On 13 Apr 2021, at 1:52 pm, gjr80 <[email protected]> wrote: > > To understand why you are seeing this behaviour you need to understand how > Almanac objects are created and how they are created within a Cheetah > template/WeeWX report. > > An Almanac object needs, among other things, a unix epoch timestamp when > it is created. If the Almanac constructor does not include a timestamp > the current system time is used. The key point here is that the timestamp > is a unix epoch timestamp, ie seconds since midnight GMT/UTC 1 January > 1970. When you use an $almanac.xxx tag in a CheetahGenerator template the > CheetahGenerator obtains an Almanac object (to provide all of the > $almanac.xxx tags) and uses the report generator timestamp (a unix epoch > timestamp) to initialise the underlying Almanac object. You have not > shown us the code in your GE skin, but for the purposes of the exercise I > will assume it is similar to some of the existing forecast extension and > clones code. The forecast variable available in the forecast skin has an > almanac property (which works just like the $almanac tag) that can be > used to obtain various tags, commonly sun/moon rise/set etc. The forecast > extension also operates across a number of days and almanac properties for > each day are obtained by initialising the almanac with a timestamp for each > day (period), for example (my indentation): > > #for $period in $periods > #set $img = '' > #set $alm = $forecast.almanac(ts=$period.event_ts.raw+10) > #if $alm.hasExtras > #set $moonrise_ts = $alm.moon.rise.raw #set $moonset_ts = > $alm.moon.set.raw > > Here the almanac is initialised not with the current epoch timestamp or > generator timestamp but with a tag ($period.event_ts.raw) that is going > to be in the group_time units that apply to the skin. When group_time is > set to unix_epoch you get seconds since epoch, if you use unix_epoch_ms you > get milliseconds since unix epoch or 1000 time the former. This is what > causes the overflow and this is why changing group_time causes the error > to appear/disappear. > > Is it a bug, maybe, but I don't think it is. class Almanac needs a > timestamp, the class says it needs to be initialised with a unix epoch > timestamp but that is not what it is being given. If you ask WeeWX to > convert degree C to hPa is it a bug if WeeWX throws an error? > > Solutions? class Almanac could be made handle a timestamp in unix epoch > seconds or milliseconds as it is generally pretty easy to tell the > difference, though not for all date-times. Not sure on Tom's view on that > though, does feel a little hackish to me. Alternatively, templates/SLEs etc > could just force any timestamps being passed to $almanac() (or in this > case $forecast.almanac()) be be in unix_epoch seconds, just like we force > units in some formulae to degree C or m/s etc. So in this case something > like (untested): > > #for $period in $periods > #set $img = '' > #set $alm = $forecast.almanac(ts=$period.event_ts.unix_epoch.raw+10) > #if $alm.hasExtras > #set $moonrise_ts = $alm.moon.rise.raw #set $moonset_ts = > $alm.moon.set.raw > > should work. > > Gary > > > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/8dd1b742-8236-4db4-ab19-dc162acc213bn%40googlegroups.com.
