On 22/03/16 08:17, Ken McDonell wrote:
...
Now everything is OK, EXCEPT for ...
pmLocaltime from int: 1388688379.0 (2014, 1, 3, 4, 46, 19, 1, 33, 0)
pmLocaltime from float: 1388688379.0 (2014, 1, 3, 4, 46, 19, 1, 33, 0)
Where does the value 1388688379 come from? It looks sort of like a time_t, but
is 754 hours earlier than the input time_t!
The other values at the struct tm fields (I guess) and these values appear to
be correct.
Can someone explain where this number comes from and how this fragment of
Python is producing it ...
print("pmLocaltime from int: %s" % str(context.pmLocaltime(sample_time_i)))
print("pmLocaltime from float: %s" % context.pmLocaltime(sample_time_f))
I think it is coming from here in pmapi.py (Nathan, this looks like your
code) ...
inseconds = 0.0
try:
inseconds = time.mktime(timetuple)
except:
pass
return "%s %s" % (inseconds.__str__(), timetuple)
I don't see the point of this ... inseconds can _never_ be anything
useful, as it will be constructed using the _local_ timezone, not the
PMAPI TimeZone. And indeed this number is the value above for all hosts
in Melbourne, but something quite different for grundy.sgi.com in the USA.
Why don't we skip all the inseconds stuff and simply
return str(timetuple)
>
> and why is str(..) needed in the first case, but not the second?
and I still have no clue on this.
|