30,997
edits
Language and development rules: Difference between revisions
Jump to navigation
Jump to search
m
→Dates and Timezones
Tag: 2017 source edit |
Tag: 2017 source edit |
||
| Line 507: | Line 507: | ||
And all select methods should translate date fields, coming from the database as a string in TZ of server (here '19700101000000') by using $db->jdate(..., 'gmt'); | And all select methods should translate date fields, coming from the database as a string in TZ of server (here '19700101000000') by using $db->jdate(..., 'gmt'); | ||
'''Other cases''' | |||
*Dates that are updated automatically (field '''tms''' into database) contains a GMT Timestamp of the date when the change is done. The select will also use the db->jdate (that use PHP server TZ) to convert read data into a GMT Timestamp into memory. So if timezone of database differs from timezone of PHP server (one of them is not correctly set), you may experience differences between creation date and update date. Try to never rely on this field in Dolibarr (this autoupdate field is mostly for debug purpose). | *Dates that are updated automatically (field '''tms''' into database) contains a GMT Timestamp of the date when the change is done. The select will also use the db->jdate (that use PHP server TZ) to convert read data into a GMT Timestamp into memory. So if timezone of database differs from timezone of PHP server (one of them is not correctly set), you may experience differences between creation date and update date. Try to never rely on this field in Dolibarr (this autoupdate field is mostly for debug purpose). | ||