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 491: | Line 491: | ||
*A date into memory must always be stored with Timestamp GMT format. | *A date into memory must always be stored with Timestamp GMT format. | ||
*A date stored into database, is the GMT Timestamp of date submitted into the request usng the <b>PHP server</b> timezone. This does not apply to date | *A date stored into database, is the GMT Timestamp of date submitted into the request usng the <b>PHP server</b> timezone. This does not apply to date updated automatically by the database engine (fields '''tms''' into database). | ||
For exemple le 1st january 1970, 3 hour at Paris (TZ=+1) = 2 hour at Greenwitch (TZ=0) will be stored into memory with value 7200 and will be submitted into a SQL request to database | For exemple le 1st january 1970, 3 hour at Paris (TZ=+1) = 2 hour at Greenwitch (TZ=0) will be stored into memory with value integer 7200 (2 * 3600s) and will be submitted into a SQL request to database into the string '19700101030000' (PHP convert the int into its TZ hour and database will unconvert it using its timezone too that is same than PHP). | ||
*How to manage this for date with hours:* | |||
*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. | So all insert or update methods must convert, during generation of SQL request, the integer memory date into a db string by using db->idate (you may find examples into skeleton). | ||
And all select methods should translate date fields, coming from the database as a string in TZ of server (here '19700101030000'), into a timestamp field (integer) by calling the method db->jdate(). So this stores the date into memory as a GTM Timestamp integer. | |||
*How to manage this for date with no hours:* | |||
For insert/update, you must convert it with db->idate(value, 'gmt') so for 0, you will get '19700101000000'. | |||
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). | |||
*Manipulation date with PHP must be done using the Dolibarr date functions: '''dol_now(), dol_mktime(), dol_stringtotime(), dol_getdate(), dol_time_plus_duree()'''. You may also find other functions available into file '''date.lib.php'''. | *Manipulation date with PHP must be done using the Dolibarr date functions: '''dol_now(), dol_mktime(), dol_stringtotime(), dol_getdate(), dol_time_plus_duree()'''. You may also find other functions available into file '''date.lib.php'''. | ||