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

UTCTime constructors are broken #26

Open
rwpenney opened this Issue Jan 20, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@rwpenney
Contributor

rwpenney commented Jan 20, 2017

The UTCTime class is supposed to allow construction from a tuple of year/month/day/hour/minute/second, but the implementation does not appear to actually use those values at all. For example, the following initialization (taken from UTCTime::test()):

gpstk::UTCTime utc(short(2002),short(1),short(1),short(0),short(0),0.0);
std::cout << "UTC "<< utc << std::endl;

produces:
UTC 0000000 00000000 0.000000000000000 UNK

Looking at the implementation of these constructors (in https://github.com/SGL-UT/GPSTk/blob/master/ext/lib/Geodyn/UTCTime.hpp), there appear to be CivilTime and YDSTime objects created, but these don't appear to have any influence on the internal state of the construted UTCTime instance.

Am I not using these constructors correctly, or do they not work as intended?

@rumkex

This comment has been minimized.

Show comment
Hide comment
@rumkex

rumkex Jan 20, 2017

I think you are supposed to use CivilTime class for that, it allows to do exactly the same things, and is part of the core library.

UTCTime appears to be somewhat of a work-in-progress. Fixing this issue by itself is easy enough, but does it have a point? We could be scratching the surface of a hornet nest here.

rumkex commented Jan 20, 2017

I think you are supposed to use CivilTime class for that, it allows to do exactly the same things, and is part of the core library.

UTCTime appears to be somewhat of a work-in-progress. Fixing this issue by itself is easy enough, but does it have a point? We could be scratching the surface of a hornet nest here.

@rwpenney

This comment has been minimized.

Show comment
Hide comment
@rwpenney

rwpenney Jan 20, 2017

Contributor

Thanks for the pointer to CivilTime.

I agree that fixing UTCTime should be very straightforward.

I really hope that fixing code that is already part of the documented part of the library, and which clearly does not behave sensibly in a very simple use case, would not disturb any hornets!

Contributor

rwpenney commented Jan 20, 2017

Thanks for the pointer to CivilTime.

I agree that fixing UTCTime should be very straightforward.

I really hope that fixing code that is already part of the documented part of the library, and which clearly does not behave sensibly in a very simple use case, would not disturb any hornets!

@eborovenskiy

This comment has been minimized.

Show comment
Hide comment
@eborovenskiy

eborovenskiy Jan 23, 2017

Hello. I tried to fix some problems with UTCTime. Now it works for me.

UTCTime.hpp.txt
UTCTime.cpp.txt
IERS.hpp.txt

eborovenskiy commented Jan 23, 2017

Hello. I tried to fix some problems with UTCTime. Now it works for me.

UTCTime.hpp.txt
UTCTime.cpp.txt
IERS.hpp.txt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment