Hi Roy
On 27/08/2008, at 5:47 AM, Roy Lyseng wrote:
Morgan Tocker wrote:
I haven't dug into the DATETIME
data type code yet, but it shouldn't be too incredibly difficult to
implement. Does anyone else see this as a useful feature?
Yeah, the no milli/micro thing has always annoyed me. If someone on
this list manages to fix this, how much additional work is required
so
that the timezone component of a datetime is also stored?
Also - is it possible to change datetime to require less storage
space? Currently we have:
DATE - 3 bytes.
TIME - 3 bytes.
DATETIME - 8 bytes.
The range of DATETIME is no more than DATE + TIME as two separate
columns.
A DATETIME column with a standard-compliant YEAR component
(0001-9999) and microsecond precision takes up around 7 bytes, so
rounding up to 8 bytes is not a big overhead.
Excellent.
What Morgan was referring to is the current implementation quirk that
DATETIME, while not storing fractional seconds, takes 8 bytes to store
the same info that date and time store in 6 separately. Modifying
DATETIME to include fractional storage and at the same time cleaning
up the storage format would be great; going by your info, it won't
take any more space than it already does now!
Notice that time/datetime data types with and without timezone has
pretty different semantics, so it is a fairly big job.
Timezones in db must die!! Problem solved.
Cheers,
Arjen.
--
Arjen Lentz, Founder @ Open Query
Training and Expertise for MySQL in Australia and New Zealand
http://openquery.com.au/training/ (ph. +61-7-3103 0809)
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
