not sure - maybe bug? comes when adding specials to the products

[Doomm]

Hi guys,

when trying to add specials, sometimes (not always) I recieve a blank page with famous

WARNING: An Error occurred, please refresh the page and try again...

after looking into the logs, I have found this:

[28-Dec-2019 12:12:16 UTC] Request URI: /admin/specials.php?manual=1&action=update, IP address: 85.216.177.250
#1 trigger_error() called at [/public_html/includes/classes/db/mysql/query_factory.php:171]
#2 queryFactory->show_error() called at [/public_html/includes/classes/db/mysql/query_factory.php:143]
#3 queryFactory->set_error() called at [/public_html/includes/classes/db/mysql/query_factory.php:270]
#4 queryFactory->Execute() called at [/public_html/admin/specials.php:103]

--> PHP Fatal error: 1292:Incorrect date value: '20282712' for column 'expires_date' at row 1 :: UPDATE specials
SET specials_new_products_price = '15.7500',
specials_last_modified = now(),
expires_date = '20282712',
specials_date_available = '0001-01-01'
WHERE specials_id = 100 ==> (as called by) /public_html/admin/specials.php on line 103 <== in /public_html/includes/classes/db/mysql/query_factory.php on line 171.


expires_date seems to be a problem here, not sure why

[mc12345678]

What sub-version of ZC 1.5.6 are you using?

Ignore the below for this topic... barking up the wrong tree...


This is from some things over the years, but basically the direction mysql has been going is that a date or datetime that is formatted as beginning like: 0000-00-00 is invalid. Unfortunately there have been situations in the past where date/datetime fields have been set with that value instead of null or some other known "arbitrary" value. Zen Cart has otherwise been using 0001-01-01 as that arbitrary value, but even that has become questionable for even more recent versions of mysql.

At any rate, the lastest version of ZC 1.5.6 has a sort of patch run during the upgrade process that should/should have addressed that issue and the current code should have prevented it from happening, but... :)

[mc12345678]

I note that there is a line difference between the reported error location and where the associated 1.5.6x code is located. There is a line before the query that is supposed to request the end date to be processed through a date handler that likely should prevent the above issue. Wonder either why the line difference (missing three lines) or if there is something in that processing that is not adding/applying the appropriate date processing. Also, does this seem to happen only with certain browsers or devices? (e.g. While on a mobile, using one or the other browsers?)