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

fix microseconds leading zeroes #277

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

Baxulio
Copy link

@Baxulio Baxulio commented Aug 3, 2023

  1. We have TIMESTAMPTZ field with value: '2023-07-31 16:19:49.91874'
  2. if we map it to trantor::Date class and invoke ::toDbLocalString() it returns '2023-07-31 16:19:49.091874'

The microseconds part is converted incorrectly, because 91874 is not equal to 091874. It should be '2023-07-31 16:19:49.918740'

e.g. https://stackoverflow.com/questions/62937930/postgres-timestamp-with-microseconds

1. We have TIMESTAMPTZ field with value:  '2023-07-31 16:19:49.91874'
2. if we map it to trantor::Date class and invoke ::toDbLocalString() it returns '2023-07-31 16:19:49.091874'

The microseconds part is converted incorrectly, because 91874 is not equal to 091874. It should be '2023-07-31 16:19:49.918740'
@VladlenPopolitov
Copy link
Contributor

I look at your pull request, as I use these functions in my program, and it will affect my program. I think, you have other problem in your code - data are broken somewhere between database and trantor::Date::toDbStringLocal(). You propose changes, that are not correct - they calculate wrong in opposite direction and fix previous error in code, but it will work wrong in all other programs, that does not have this first error.
Could you look at your code again? Probably the problem in Postgres driver and it wrongly convert timestamp to trantor::Date, or you have other conversion function from string to trantor::Date (not fromDbStringLocal). As I see - toDbStringLocal and fromDbStringLocal calculates correct, %06d is correct, and trailing zeroes added correctly.

std::string testString = "2023-07-31 16:19:49.91874";
auto date1 = trantor::Date::fromDbStringLocal(testString);
auto testString2 = date1.toDbStringLocal();

fromDbString and toDbString now has bug (I unintentional introduced it when sent other bug fix), I hope patch will be applied in nearest time.

@Baxulio
Copy link
Author

Baxulio commented Aug 20, 2023

Ok, maybe my solution is wrong, but the obvious thing is, there is a bug regarding to time conversion to string.

Steps to reproduce:

  1. create table History with time column
  2. insert a row with time ("2023-07-31 16:19:49.91874")
  3. create DTO History using drogon_ctl
  4. fetch the row from DB and assign to History object (history)
  5. call history.getValueOfTime().toDbStringLocal()

The result will be: "2023-07-31 16:19:49.091874"

@VladlenPopolitov
Copy link
Contributor

Sorry to say, but it is not obvious. On my computer everything works OK, I use Postgres 15.4 and latest commit from trantor (master HEAD).
Could you say you database engine name end version? And what is your operation system and version - Windows, Linux, macOS?

Could you check step 2: check by any tool, what exact value inserted into the table History? If problem with driver, error can be on this step.

Could you check in debugger step 5:

  1. step into history.getValueOfTime() and look at value of time_ member? Are last 6 digits 091874 or 918740? In first case problem somewhere before, see 2). In second case step into toDbStringLocal() and try to see, where is mistake, but I do not see, where can be mistake in that code - it is short, you easy check it.
  2. if last 6 digits are 091874, you have to look at constructor of history variable - how data are populated. Step into the constructor and check part of code, where time_ is assigned. It started by code
    auto timeStr = r["time"].as<std::string>();
  3. if timeStr also is not correct, the problem in database engine driver - drogon takes timestamp value from driver as string.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants