Support for microseconds

[hubipe]

• bug fix? no
• new feature? yes
• BC break? maybe

Database systems support microseconds in datetime columns, but Dibi always escaped datetime values without second fractions. Therefore even if the datetime column in database is set to accept second fractions, it would always store just full second. I changed formatting rules to include second fractions with date format u (supported since PHP 5.2.2).

If database system is not set to use second fractions, it should beignored, however I'm not sure, if other databases than MySQL, MSSQL and Postgres support time fractions, so I've changed just these drivers.

[dg]

Thanks. Can you fix tests too?

[milo]

This can be BC break. In PostgreSQL you can define column as timestamp (no limitation) or timestamp(0) (it trims second fragments). After this change, the timestamp column will be filled with microseconds too which wasn't before.

Personally, I'm 👍 for this.

[hubipe]

Sorry, I've been busy. I'll do my best and will try to update tests by this weekend.

[hubipe]

I've updated the tests

[dg]

Thanks

[Ciki]

If database system is not set to use second fractions, it should beignored, however I'm not sure, if other databases than MySQL, MSSQL and Postgres support time fractions, so I've changed just these drivers

@hubipe can you give a source for this statement? I've come across this issue as it's BC BREAK in my opinion .. when the datetime column stores only full seconds, then any comparison using also fractions will fail.. Am I missing sth.?

cc @dg

[dg]

In MySQL 5.7.20 comparsion of datetime column with full seconds and fraction seems to work ok.

[hubipe]

Same in PostgreSQL 10.1 and MSSQL 2008r2.
What comparison are you using? And what database system?

[Ciki]

check MySQL 5.6 version, example here

tested on 5.6.17 and also MariaDB 10.1.26

[hubipe]

I see what are you referring to. In my opinion this is expected behaviour. Compare it with this modified example. When you compare date time column with 0 microseconds it is automatically presumed, that microseconds are 0. Thus comparing with microsecond time with any different microseconds than 0 will result in empty result.

In this way, that PR might be considered as a BC break, if you had depended on this falsy behavior. The question is, if it should stay as it is and you should fix your code not to use microseconds, or if dibi should make a change

[Ciki]

Yes, I agree.

$dt = new DateTime(); // https://secure.php.net/manual/en/datetime.construct.php for php >=7.1 microseconds are filled with actual value. Not with '00000'.
dibi::insert(table, [date=>$dt]); // inserts record without the microseconds
dibi::select(*)->from(table)->where('date=%dt', $dt); // empty result

this example and similar use cases worked prior this PR regardless the php version used. With this PR they work seamlessly with php <=7.1 only.

[hubipe]

What shall we do then? We can either withdraw this PR and think of different solution (maybe new keyword %tm?) to support microseconds, or leave it as it is and mark it as backward incompatibility. @dg?

(Arrghh I hate PHP inconsistency!)

[Ciki]

@dg do you find it correct|expected|safe behaviour regarding BC as well?

[dg]

Correct me if I'm wrong, this affects only cases when you create new DateTime without arguments in PHP >= 7.1, right?

I think the easiest solution would be keep this PR, add notice to older releases and add helper function that strips microseconds from DateTime.

Something like:

$stripped = dibi::stripMicroseconds(new DateTime);  // or stripMicrotime?

[Ciki]

yes, you are correct.

as long as there is a notice about this change in docs I agree with your proposal in all points