time stamp on create corresponds to what?


I was trying to diagnose what time the ‘lastTimeStamp’ on the client create call corresponds to.

I am using the README.md in the python install file as a template.

the python libraries datetime and pytz and OSX 10.14

I divided the timestamp by 1000 and got a good year, day and date but I’m having trouble with the hour.

Assuming UTC, I’m off by maybe 4 hours (I can’t get that daylight savings time thing figured out). Assuming local time, I’m off by 2 hours.

My typical hack would be to set/readback/generate an offset to the known time and use that offset as a calibration factor.

But I’d like your confirmation of what the timestamp is set against before going this route.

Any help?

bob s.

Retrying the same code on the next day with diagnostics code added.
I restarted the server, deleted then recreated the key. And, of course, the timestamp now starts at 0.

More testing. The timestamp jumps from 0 to unix time!

Partially copying and implementing the code from the readme file:

rts.range(‘test’, 0, -1)

rts.range(‘test’, 0, -1, aggregationType=‘avg’, bucketSizeSeconds=10)

rts.range(‘test’, 0, -1, aggregationType=‘sum’, bucketSizeSeconds=10)


Printing out the ranges and the info:

range= [(1, ‘1.1200000000000001’), (2, ‘1.1200000000000001’), (1566313204640, ‘2.1200000000000001’)]

range-avg= [(1566313204640, ‘1.4533333333333334’)]

range-sum= [(1566313204640, ‘4.3600000000000003’)]


{‘chunkCount’: 1,

‘labels’: {‘Time’: ‘Series’},

‘lastTimeStamp’: 1566313204640,

‘maxSamplesPerChunk’: 360,

‘retention_msecs’: 0,

‘rules’: [],

‘sourceKey’: None}

Can you explain what is going on at the server side?

The timestamp / 1000 does correspond to UTC time, per my “atomic” G-shock wristwatch.
So that’s one less thing to worry about.

Hello Robert,

If I understand correctly, you got the answer by now. Thank you for sharing it with the community.

Please feel welcome to ask any further questions.