|
|
Cross platform date function fix
- General
Posted by mocha (Thursday October 05 2000 @ 11:57PM EDT) views: 328 |
after submitting my previous post regarding why the date we set to 2036-11-12 and wrong time for submitted stories and comments, i dug through the codes and found that Jason did the standard thing and used mysql's NOW() function.
Apparantly on 64-bit system w/o native threads, mysql uses MIT-threads. Consequently the time() returned is incorrect in most circumstances when you use mysql's NOW() function.
In order to fix this problem, i used PHP's
date("Y-m-d G:i:s")
in place of NOW() for all occurances of NOW() in preview.php and include/common.inc.php.
Jason, if you would like the diff for those files, please let me know.
Here is an output of a select statement to demonstrate what i'm talking about:
mysql> select Rid,Timestamp,Birthstamp FROM T_Stories;
+------------------+----------------+---------------------+
| Rid | Timestamp | Birthstamp |
+------------------+----------------+---------------------+
| 00/10/05/5569922 | 20361112031114 | 2136-11-11 10:14:25 |
| 00/10/05/3425315 | 20361112005749 | 2136-11-11 12:25:21 |
| 00/10/05/5725052 | 20361112030000 | 2136-11-12 02:57:01 |
| 00/10/05/7952565 | 20361112024756 | 2136-11-11 13:40:48 |
+------------------+----------------+---------------------+
4 rows in set (0.00 sec)
mysql> select now();
+---------------------+
| now() |
+---------------------+
| 2136-11-12 05:21:55 |
+---------------------+
1 row in set (0.00 sec)
Now all I need to do is go back and update the fields and correct the Timestamp and Birthstamp for relevant tables. Jason, how do I turn the Rid field into a timestamp? The date is obviously there already, however the time.microsecs is in a weird format. Any help is appreciated cause those records currently always stay above all the rest in the story page.
|
|
|
|
By jason (Friday October 06 2000 @ 11:37AM EDT)
|
Ahh. I did not know this..
To generated a Rid, use the function F_getRid();
|
|
[ reply | parent ]
|
|
By mocha (Friday October 06 2000 @ 12:39PM EDT)
|
further looking into the db schema, you used 'timestamp' for some of the fields. even with the fix i sent previous, timestamp fields will use the current time from mysql which would be yield an incorrect value because of the bug in mysql on 64-bit systems. there are two resolutions to this problem:
1. change the db schema for the fields that use timestamp to a datetime field and change SELECT and INSERT functions in phpweblog to update those fields (which were automatic before).
2. i submitted a patch to MySQL to fix the timestamp and NOW() function. basically the bug in mysql is in mit-pthreads. in the file:
mit-pthreads/gen/ctime.c
the function detzcode() should be defined and return as an INT instead of a LONG. the bug works fine if you are in a positive GMT timezone on a 64-bit architecture, because it's stuffing the GMT offset into a 64-bit long rather than a 32-bit int. however, if you are in a negative GMT timezone, it turns the negative offset into one huge positive offset. here is the fix for mysql 3.23.25-beta (should work with previous versions as well):
---cut---
# diff mit-pthreads/gen/ctime.c.orig mit-pthreads/gen/ctime.c
132c132
static int detzcode __P_((const char *));
178c178
static int detzcode(const char * codep)
180c180
int result;
---cut---
MySQL should have this fix in their next beta or release. i guess we could stick with using the timestamp fields in our tables.
|
|
[ reply | parent ]
|
|
|
|
