Well, for presentation purposes that is probably useful more often.
It’s a longstanding problem with the datetime module that an
assortment of conversions are hard to do. I think it’s a bit better than
it used to be. I think the common thing these days is to use a third
party library like python-dateutil or arrow (I use both
occasionally, ugh).
I blame timezones, which are annoying and nontrivial.
My most recent bitter dispute with times is my solar inverter
controller, or at least the Windows utility which talks to it. (In
reality, probably both). It will export CSV data with both a human
datetime-style column and a seconds-since-epoch column (coming from a
Windows culture, these are in “local time”). What, the
seconds-since-2001 epoch timestamp has an implied timezone? Why, yes, it
does! Ugh!
For reference, I’m using this to get the base epoch:
def ts2001_unixtime(tzname=None):
''' Return the SP-Link 2001-01-01-local-time epoch as a UNIX time.
'''
if tzname is None:
tzname = 'local'
a2001 = arrow.get(datetime(2001, 1, 1, 0, 0, 0), tzname)
unixtime = a2001.timestamp()
return unixtime
and the import code looks like this:
@staticmethod
def csv_tagsets(csvpath):
''' Yield `(unixtime,TagSet)` 2-tuples from the CSV file `csvpath`.
'''
ts2001_offset = ts2001_unixtime()
_, rows = csv_import(csvpath)
for row in rows:
tags = TagSet()
for attr, value in row._asdict().items():
try:
value = int(value)
except ValueError:
try:
value = float(value)
except ValueError:
pass
tags[attr] = value
when = float(
row.date_time_stamp_seconds_from_the_year_2001
) + ts2001_offset
yield when, tags
The inverter knows nothing about timezones. So the other week the
software offered to adjust the inverter time, and I finally gave in. Now
I’ve got an annoying 1 hour gap in my plot data at that point. I presume
I’m going to have a 1 hour data loss when I shift it the other way at
some point.
Cheers,
Cameron Simpson cs@cskk.id.au