Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

timestamps should be integers when sending to middleware #146

Closed
andig opened this issue Mar 19, 2015 · 7 comments
Closed

timestamps should be integers when sending to middleware #146

andig opened this issue Mar 19, 2015 · 7 comments
Assignees

Comments

@andig
Copy link
Contributor

andig commented Mar 19, 2015

From the ml:

[ [ 1426414635584.1191, 1658272.1000000001 ] ]
vzlogger sendet die timestamps als float? nicht soo sinnvoll...

@mbehr1
Copy link
Contributor

mbehr1 commented Mar 19, 2015

That's easy to fix.

        json_object_array_add(json_tuple, json_object_new_double(value));

can be changed to use int64.
I'm just worried that somebody parsing the output expects a json type double and can't handle int64.

@andig
Copy link
Contributor Author

andig commented Mar 19, 2015

Shouldnt happen. An int64 is still a float imho.

@mbehr1 mbehr1 self-assigned this Mar 20, 2015
@mbehr1
Copy link
Contributor

mbehr1 commented Mar 22, 2015

Does anybody mind if I change the internal storage of timestamps to int64_t as well? Seems like nobody really needs the doubles and the int->double->int conversions.
Btw: does anybody use the mysmartgrid api? Seems like this uses int for timestamps as well (but rounded to seconds).
This would mean changing the following parts of class Reading:

    double tvtod() const;
    double tvtod(struct timeval const &tv) const;
    void time() { gettimeofday(&_time, NULL); }
    void time(struct timeval const &v) { _time = v; }
    struct timeval dtotv(double const &ts) const;

and all the users of it.

@andig
Copy link
Contributor Author

andig commented Mar 22, 2015

Dont think anybody cares about the actual implementation details.

@mbehr1
Copy link
Contributor

mbehr1 commented Mar 22, 2015

see PR #148.

@mbehr1
Copy link
Contributor

mbehr1 commented Apr 11, 2015

can be closed, right?

@andig
Copy link
Contributor Author

andig commented Apr 11, 2015

Of course, thank you!

@andig andig closed this as completed Apr 11, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants