Josh Berkus wrote:
Giuseppe,
I'd say that adding (non compulsory) TZ information to the datetime
field is going to be good for users.
The only case where it makes sense to *store* the time zone
information in the field is when, for some bizarre reason, we want to
know time zone a time was recorded in, but will also have multiple
users from multiple time zones recording times, and don't want to see
times recorded by other users in their own local times. In 13 years
of database work, I've never encountered such a use case.
Pardon me for butting in late, but shouldn't simplification rule, other
things being equal? A single timestamp type defined as UTC/GMT/Zulu
(pick one) with nanosecond precision is all that anyone would ever
actually need. If somebody wants to track the original timezone (why?),
let him/her define a separate field to do so.
I'm dumping types right and left in Nimbus. It's good for the soul.
Compress the data so the type becomes irrelevant. Dump character sets
in favor of Utf-8; left the client side do character set conversions.
For Nimbus DDL types, I'm supporting "number" and "string" (no precision
or lengths). Why bother with anything else? Internally, types should
be driven at runtime, not DDL time.
(Josh, I don't disagree with you; this was just a convenient place to
jump in.)
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
