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/8BCD6A36-D6CF-4B41-B41F-455CD75C7025%40gmail.com.
