apologies for the many tickets by the way

Don't worry, your feedback is appreciated :)

Actually, the time_precision parameter is not meant to convert your time precision. So I guess that's a feature request?

Hmm, that might be handy if it's not a feature already :)

It looked like the time parameter was getting converted though, i.e. I was specifying a timestamp down to microsecond precision with:

'time': '2015-07-27T12:55:48.165231Z'

which was then sent as:

1438001748165231104

So it looks like it added '104' as nanoseconds from somewhere, instead of sending the value as '1438001748165231', which was the data specified in the 'time' field as a string.

@dschallis , just to confirm, the new feature you'd like is to specify a given time and the requested precision (e.g. microseconds) and have the influxdb library add the padding, is that correct?
So, for example you would like to pass a time such as 'time': '2015' and have the library actually log 2015-01-01T00:00:00.0. Is that correct?

@ChristopherRabotin I think it was more the other way around, i.e. if I specify 'time': '2015-01-01T01:01:01.123456' and specify precision as seconds, then send data as a timestamp in seconds, instead of as time since epoch in nanoseconds.

@aviau , do you reckon this should be a feature to be supported in this client? I think it should be supported at the InfluxDB level directly, especially to avoid having different clients behaving in different ways.

I was under the impression that most users sent integers anyways. The way its implemented in #224 is not intrusive as you can just send integers and it won't be touched.

Just to clarify a little. Implementation in #224 also handles time_precision (s, ms, u, n) correctly even if timestamps are coded as date-time strings. Not sure how InfluxDB handles it if time_precision is minute or hour (m, h), though. It probably rounds off minutes and hours part from epoch seconds? Needs tests and enhancements, potentially.