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 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
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
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
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
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
