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/CAPq0zECqZSFaxQM2%2B9%3De8HgBeH088iWGK6wBvO9%3D0C89arnEDA%40mail.gmail.com.
