+1 On Sat, Jan 10, 2009 at 12:16 AM, Jay Pipes <[email protected]> wrote: > OK, so based on people's input, does the following sound reasonable? > > Keep CURRENT_TIMESTAMP() and make NOW() a synonym for that function and > remove all other functions? > > Regarding CURTIME() and CURDATE() (and associated synonyms) we'll deal with > that in a little bit. For right now, we are solely concerned with > timestamp-related functionality. > > Also note that we are strictly talking about functions and not data types > for right now... > > Votes please :) > > Jay > > Roy Lyseng wrote: >> >> >> Jay Pipes wrote: >>> >>> All: >>> >>> As you may know, Drizzle does not support timezones. All >>> datetimes/timestamps are stored and operated upon using UTC. >>> >>> Due to this, it looks like the NOW() function and some of its brother and >>> sister synonym functions will overlap the functionality of the >>> UTC_TIMESTAMP() function. >>> >>> According to the manual, the NOW() function: >>> >>> "Returns the current date and time as a value in 'YYYY-MM-DD HH:MM:SS' or >>> YYYYMMDDHHMMSS.uuuuuu format, depending on whether the function is used in a >>> string or numeric context. The value is expressed in the current time zone." >>> >>> According to the manual, the following functions are all synonyms for the >>> NOW() function: >>> >>> CURRENT_TIMESTAMP >>> CURRENT_TIMESTAMP() >>> LOCALTIME >>> LOCALTIME() >>> LOCALTIMESTAMP >>> LOCALTIMESTAMP() >>> >>> However, due to Drizzle only supporting UTC, the following functions will >>> be identical to NOW() as well: >>> >>> UTC_TIMESTAMP() >>> UNIX_TIMESTAMP() (called with no args) >>> >>> Questions for everyone to discuss/vote on: >>> >>> OK, seriously, do we need all these synonyms?! Can we standardize on one >>> or two that best represent the result and purpose of the function? >>> >>> Personally, I think that UTC_TIMESTAMP() is the most descriptive, but can >>> see CURRENT_TIMESTAMP() as OK too. Keeping NOW() may be good for people >>> moving from MySQL to Drizzle, however, it may introduce issues where the >>> user assumes the behaviour of NOW() to use timezones. >> >> These are the standard types: >> CURRENT_DATE >> CURRENT_TIME >> CURRENT_TIMESTAMP >> LOCALTIME >> LOCALTIMESTAMP >> >> Obviously, there is no reason to keep neither LOCALTIME nor LOCALTIMESTAMP >> due to lack of local time types. UTC_TIMESTAMP should be deleted - UTC is >> implicit in CURRENT_TIMESTAMP. NOW can be kept as a synonym, I guess. >> >> Note also that the standard defines e.g CURRENT_TIME(precision), where >> precision defines the split-second precision of the value. Even though >> Drizzle does not currently support arbitrary time precision, I'd suggest you >> delete the CURRENT_TIME() syntax because it is redundant and it might be >> confused with the precision specification syntax. >> >> Thanks, >> Roy >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~drizzle-discuss >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~drizzle-discuss >> More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~drizzle-discuss > More help : https://help.launchpad.net/ListHelp >
-- Roland Bouman http://rpbouman.blogspot.com/ _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
