> > (also, at least one person said unix timestamps don't have time zones, > which is absolutely untrue -- on the machines I've worked on, the timestamp > is # of seconds since the epoch until the current system time -- which is in > a time zone! And there's no way for it to be true, because there's no way a > machine knows what the "real" date is....it could trust an ntp server, but > it still doesn't guarantee that the ntp server is correct.) >
Wait, what? The Epoch is defined as 1970-01-01 00:00:00 UTC. Any (valid) unix/posix timestamp is in terms of UTC, not local time. I've only been half-following this conversation- but I'd like to commit my 2 cents. Storing temporal information in a DB with any dependence on TZ seems silly to me. Especially when you consider that drizzle is geared towards the cloud. You can have DBs across the country syncing with one-another. Distributed web servers, again, scattered across the globe for redundancy and load distribution... all of which in arbitrary timezones. And of course,t he clients are going to be in whatever timezone most suits them... info coreutils "date input format" Has a rather amusing quote that I think describes the problem of temporal representation quite well. Of course, if a unix timestamp is what you want, then the TIMESTAMP data type is going to be more suitable. Though I'm not sure what you do after 2038 when the type hits its upper limit.
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
