Dave, On Thu, Jan 08, 2004 at 09:57:46AM +0900, Dave G wrote: > Because of time zone differences between my web site's intended > audience (Japan) and my server's location (Nevada), I've found that it's > most efficient, or at least most simple, to do all my time calculations > in PHP. > Up to now, I've still been storing all my dates in native MySQL > time formats - like DATETIME. However, this requires a bit of format > conversion between PHP and MySQL.
As far as I know, DATETIME doesn't know the difference between 'equal' times that occur during the change from summertime to wintertime. E.g. when the local time is set back from 3:00 am to 2:00 am, DATETIME won't distinguish between 2:00 am before and 2:00 after the change, so your conversion might not even be correct for every time. > What I'm thinking now is that it might just be easier for me to > store the date as a UNIX timestamp format in MySQL as a simple ten digit > long integer (Unix timestamps are ten digits, aren't they?). That way I > can pass them to and from PHP and do all the work on the PHP side > without having to do any format conversions in my SELECT and INSERT > queries. > Is this a horribly bad idea for any reason? Is the INTEGER > format the best suited for this purpose? Any tips would be greatly > appreciated. > An unsigned int is probably more appropriate for timestamps than a signed int. Also note that the range for timestamps is 1970 until 2038 (or 2106? for unsigned ints), where DATE and DATETIME have a much greater range. Using a UNIX timestamp for birthdays might not be appropriate. Regards, Fred. -- Fred van Engen XB Networks B.V. email: [EMAIL PROTECTED] Televisieweg 2 tel: +31 36 5462400 1322 AC Almere fax: +31 36 5462424 The Netherlands -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
