It may not be as hard as I thought to get this working. Try branch `development` now.
On Fri, Apr 16, 2021 at 9:37 AM Tom Keffer <[email protected]> wrote: > Anything other than unix_epoch was not really intended to be used as the > "unit of record," so I'm not surprised this isn't working. For example, in > the template celestial.inc, you have > > #set $now = $current.dateTime.raw > > With group_time set to unix_epoch_ms, this would be in milliseconds. It > could be changed to > > #set $now = $current.dateTime.unix_epoch.raw > > and perhaps, for completeness, it should be. There are many other places > like this. > > -tk > > > > > On Mon, Apr 12, 2021 at 11:17 PM gjr80 <[email protected]> wrote: > >> 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 >> <https://groups.google.com/d/msgid/weewx-user/8dd1b742-8236-4db4-ab19-dc162acc213bn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/CAPq0zED3-0dERs-%3DXmPjhuOrFuboZKm8cQPg6A-SU%3D92AhzhAA%40mail.gmail.com.
