Invalid Created Times showing up in the transactions

[d3vnu77]

As seen in the attached images, I am getting invalid created_times showing up as 0000-00-00 00:00:00 of all transactions related to ARMS.

Attachments:

You must be logged in to view attached files.

[alexg]

Hello,

Thank you for starting a new thread for this.

I can see in your var_dump output in the other thread that your incoming deposit has a timestamp of 1596502204 which looks correct.

Since you’ve already started hacking the code, know that the timestamp is copied over in function create_deposit_rows() as follows:

private function create_deposit_rows( &$tx ) {
…

$txrow->created_time = isset( $tx->timestamp ) && $tx->timestamp ? absint( $tx->timestamp ) : time();
…
}

First ensure that you have exactly the code as released, then check to see what’s going on in that function.

Just keep in mind that it’s best not to change anything in the code. If you spot a bug let me know and I’ll fix it. So please check the FAQ under “I want to do changes to the plugin’s code.”

with regards

[d3vnu77]

Trust me, I don’t want to edit your code. Right now I’m just looking at what is happening in it so I better understand it myself. Plus I can tell your a much better coder than myself, lol. Any edits you might see is just me trying to figure out what is happening and help us both. I’m working with a fresh copy of your code now.

Also, I want to let you know I appreciate your help in this. I am at my office for the day today and I’m hoping to get this resolved and thank you for helping me.

So the $txrow->created_time is equal to the correct timestamp as you thought, and can be seen in the screenshots can you insert timestamps directly into a mysql database or do you have to convert them to YYYY-MM-DD HH:MM:SS?

Attachments:

You must be logged in to view attached files.

[alexg]

Thank you for your kind words.

The reason I insist on not modifying the code is simply so we know what we’re doing. Otherwise I wouldn’t mind.

I was like you when I finished my uni studies but then I worked at a big software company where I learned some simple engineering principles that they don’t teach you in uni. Such as taking small steps, and knowing exactly what you do on each step, which is the way of professionals.

The main mistake you’re making is that you are editing more than one thing at a time.
1. Always work on one issue at a time.
2. Always have a ticket or other working area where you collect all information about this particular issue.
3. Always start from clean code, then find the one thing that you need to change to fix a bug.
4. Always make changes only after understanding what went wrong.
5. Do not be quick to code. Only code if you really have to.

If you don’t do this then you’re not a software engineer, you’re just a hacker and you will experience regressions in your defects. i.e. you’ll think that you’ve fixed something and then it will break again. It’s really a shame that they don’t teach you these things in university.

The code should work as is. The plugin passes the timestamp to MySQL and the DB server knows how to convert it to date.

So, observe and describe the issue on clean code. Use var_dump if you have to. You can also use error_log( print_r( $array, true ) ); to write the contents of $array to your logs. Once you spot the problem, only then you can know if you have to change the code.

with regards

[d3vnu77]

I didn’t go to a university, I’ve learned coding by doing it and only when I forced to anymore, lol. I’m actually in the process of hiring more software people for almost everything else, but wanted to keep dealing with the crypto wallet in my hands if possible.

So if $txrow->created_time is set correctly, why would it not be saving to the database correctly?

[d3vnu77]

As mentioned in my other post, I ran this test on the other test wordpress installation and had the same issue with decimals in the wrong place.

However the created_time data is now being inserted into the database on the test installation, the difference between the two is the production server is using a digital ocean managed MYSQL server.

Going to test the same thing on a DO database. to see if that is an issue.

[d3vnu77]

Ok, the problem with created_time showing zero dates, seems to be an issue with Digital Ocean’s MYSQL Managed Server, I will make a somment to them about this and see what they say.

Both. new transactions and wallet adds, both have zero dates for created_time on DO’s Managaed databases, but not on the maria database on the localhost of the test box.

[d3vnu77]

Here is the ticket I sent them on the issue. Though for compatibility sake I think it might be best to convert those dates into the string format. I’m not sure?

Attachments:

You must be logged in to view attached files.

[alexg]

Hello,

Ok you have isolated the issue sufficiently. This is a good start. Thank you.

I have tested the plugin with MySQL and it should be compatible with MariaDB.

To further track down the issue, please do the following.

On the server where you can reproduce the issue, please go to the admin dashboard. Under “Bitcoin and Altcoin Wallets” you will find a “Debug” tab. Please let me know what the “MySQL version” is. For example, on my dev machine, I have 5.7.31-0ubuntu0.18.04.1-log.

The plugin takes an integer timestamp and inserts it into the created_time column of type datetime. As you say, it first converts it into a string, here. There should be something in your MySQL server logs regarding this. Perhaps a warning on the INSERT statement?

While you wait for the reply from digital ocean, I will look on the web to see in what server versions or configurations this can happen.

In summary: Please let me know what MySQL version you see in the debug tab, so I can narrow down my search. If you can also check the MySQL log, that will also be helpful.

with regards

[d3vnu77]

Man, I’m not sure if I am looking at the wrong place. But I don’t see your debug screen anywhere.

[alexg]

According to digital ocean, their managed DB is a MySQL 8, so I don’t see why it wouldn’t work.

Additionally I couldn’t find on the web any reason why an ISO8601 string would not be inserted into a datetime column, in any version of MySQL.

I asked to see the server version to ensure that you’re not on a weird type of SQL that has different rules.

You can see the MySQL version in the WordPress admin dashboard (first item in the left-side menu). There should be a panel titled “Bitcoin and Altcoin Wallets”. It has several tabs, and there’s a “Debug” tab. Under it there’s some information. We’re interested in “MySQL version”.

Alternatively, you can type into your MySQL console this: SELECT VERSION(); This will give the same information.

As for the MySQL log, there should be a way for you to access it.

Since this is a strange issue, try to access the MySQL server log. It’s your best chance to figure out what’s wrong.

You can also use a temporary table to test and see if your server behaves as expected:

CREATE TEMPORARY TABLE timestamps( created_time DATETIME NOT NULL );

INSERT INTO timestamps VALUES('2020-08-06 10:00:00');

SELECT * FROM timestamps;

What do you get as result?

[d3vnu77]

Your wordfence is blocking me, thinking Im trying to run SQL queries through the form here.. so I’ve attached an image of my response.

Attachments:

You must be logged in to view attached files.

[d3vnu77]

I am not changing your code, just outputting variable into the error log so I can see what is going on…

in wallets/includes/transactions.PHP : action_wallets_transaction()

I see you run this code to get it to MYSQL format, where you convert it to a string here… as mentioned above…

if ( is_numeric( $tx->created_time ) ) {
      $tx->created_time = date( DATE_ISO8601, $tx->created_time );
}
error_log(print_r( $tx, true ));

I echoed that to the debug.log and noticed that the string it is creating has an extra T & +0000… is that supposed to be there, see attached image.

When I try to insert that into the DO MYSQL I also get zero dates

Attachments:

You must be logged in to view attached files.

[alexg]

OK thank you for finding this. This is entirely my fault.

An ISO8601 string contains a timezone offset suffix, and this can’t be inserted into datetime columns.

The reason that this bug was not apparent before is that most coin adapters already convert timestamps to strings elsewhere. With the TurtleCoin adapter this became an issue.

Instead of DATE_ISO8601 I should have used the string literal 'Y-m-d H:i:s'. I will fix this in the next patch release of wallets. In the meantime you can do the same change in your copy of wallets.

I’m still not sure why the current code works in some cases though.

Again apologies for all this trouble. I can’t believe I missed this.

with regards

[d3vnu77]

Not a problem! Glad we could get the the bottom of this.

so I changed the line to :

$tx->created_time = date('Y-m-d H:i:s', $tx->created_time );

in transactions.php: action_wallets_transaction() method line 911

$address_map->created_time = date('Y-m-d H:i:s', $address_map->created_time );

in transactions.php: action_wallets_address() method line 1169

I can confirm, this fixed the issue.

[Author]

Posts