You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is more of a design decision question..
I see that if you have a field value of type DateTime it will be saved to Influx as a number (Epoch). Obviously because Influx does not support DateTime data objects.
But if I read these measurements back, there is no way for this library to convert it back to a DateTime.
So what's the reasoning behind the decision to convert it to a number/Epoch?
It seams a bit useless and perhaps wrong IMHO.
Perhaps the user should do the conversion himself instead of the library making this decision. Then we can decide to use Epoch, another number, or perhaps a string... At least then you have the knowledge to convert it back to the original type.
The text was updated successfully, but these errors were encountered:
For reference, here is a thread showing how many are not happy with the default behavior of JsonConvert to by default convert a date-looking string to DateTime object: JamesNK/Newtonsoft.Json#862
Yea sure 😄
I'm working on software that collects data on board vessels, and now we are implementing the ISO 19030 standard. This standard requires us to store the time including offset from UTC
We solved this by storing the the UTC time as a string and the time zone offset as a separate field and then re-creating the local time when reading out the data from Influx.
Another case is when we receive NMEA ZDA telegrams. We want to store this information in Influx. So again we have DateTime information in a timeseries database.
But if I turn the question around: Why allow DataTime object to be inserted into Influx using this library? When Influx itself does not support it?
I think the root of the problem is the default JSON conversion (that both this library and we are using). You can see from this discussion that many people argue that this is not a good thing.
This causes another problem with this library. If I store a string like "2022-01-14T10:40:00+01:00" in Influx, and that use this library to read out this string it will automatically convert it to a DateTime object where the time zone information is lost.
This is more of a design decision question..
I see that if you have a field value of type
DateTime
it will be saved to Influx as a number (Epoch). Obviously because Influx does not supportDateTime
data objects.But if I read these measurements back, there is no way for this library to convert it back to a
DateTime
.So what's the reasoning behind the decision to convert it to a number/Epoch?
It seams a bit useless and perhaps wrong IMHO.
Perhaps the user should do the conversion himself instead of the library making this decision. Then we can decide to use Epoch, another number, or perhaps a string... At least then you have the knowledge to convert it back to the original type.
The text was updated successfully, but these errors were encountered: