qa/737 started failing after my libpcp timezone changes ... but I've been
digging into qa/737 and qa/src/test_pcp_time.py.
First, test_pcp_time.py was internally inconsistent.
After # seconds-since-epoch for: "Mon Feb 3 15:46:19 2014 UTC"
there is an initialization for the time_t values that does not match this date
and time.
The value was 1391402779 but is should be 1391442379 as per the comments in the
changes I've made to the script (commit pending)
# value determined as follows: 1 Jan 1970 -> 3 Feb 2014 is 16104 days
# 16104 * 24 * 3600 1391385600
# + 15 * 3600 54000
# + 46 * 60 + 19 2779
# sum these 1391442379
#
sample_time_i = 1391442379 # integer
So, moving on to 737.out all the hours are wrong ... they are 04, not 15 ... so
may be the comment was wrong in the original code, as -11hrs would make the
time_t = 1391442379 - 11*3600 = 1391402779.
So, let me undo the 737 changes (mostly) and revert to the original time_t, but
with the comment corrected so the time is 04:46:19 not 15:46:19.
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))
and why is str(..) needed in the first case, but not the second?
|