If now i add a new product, and after 10 minutes another: the second product will be listed as the second ... must to be listed the first...like is the last product added
and if i add the third product will be listed as the third product....and so on
CS 4..2.4
It must be something I'm missing
CS-Cart stores current date only without hours, minutes and seconds. Additional code modifications are required to change this behaviour
Really? Most storage I've looked at in the DB uses the constant TIME for the 'timestamp' column (or created, etc.) in DB tables and TIME is defined as time() which is seconds from the epoch.
...means ?!
Really? Most storage I've looked at in the DB uses the constant TIME for the 'timestamp' column (or created, etc.) in DB tables and TIME is defined as time() which is seconds from the epoch.
When you add product, the current timestamp is saved. But if you update product later, the Creation date field contains only date. As a result, it saves date with 0:00 time.
Hmm... Searching fn.products.php shows both 'timestamp' and 'updated_timestamp' both being set to time() which is seconds since the epoch. According to the get_product_fields() function, "creation_date is mapped to 'timestamp'.
Where are you finding that the timestamps are being truncated to day only (I.e. no time of day)?
While the templates may indeed only show the date, the time in the database should be to the second (realtime) and hence even more accurate than the TIME constant which for an import would make all the updated_timestamps the same if it were used.
Hmm... Searching fn.products.php shows both 'timestamp' and 'updated_timestamp' both being set to time() which is seconds since the epoch. According to the get_product_fields() function, "creation_date is mapped to 'timestamp'.
Where are you finding that the timestamps are being truncated to day only (I.e. no time of day)?
While the templates may indeed only show the date, the time in the database should be to the second (realtime) and hence even more accurate than the TIME constant which for an import would make all the updated_timestamps the same if it were used.
Please check the fn_update_product function and find where the fn_parse_date function is called. I am not talking about update_timestamp parameter, but about timestamp one which is used in the sorting. This is well known issue for ages
Yes, reading and apply the date only portion from the admin UI "Create Date" does simply use midnight of the date submitted.
However, any import or other means of setting the create date uses time(). The DB itself uses an unsigned int(11) which holds a UNIX timestamp integer.
It would be quite simple then to simply add a update_product_post hook to look at the timestamp and if it matches today's date at midnight, then add back in the time and save it to the DB.
fn_parse_date() makes some bad assumptions like the year is always the 3rd element after an explode() on '/'. I.e. European date formats are not supported (2016-05-31). If it's not a '/' separated date, then it forces it to be TIME (which included time of day). Kind of a mess.
Agree with you. We have already made this modification for several websites
So seems the simplest way to get this to work properly is to simply use a '-' separated date which will force it to use time() as the value ignoring what was specified in the UI field.