Mark Atwood wrote:
On Dec 24, 2008, at 3:43 AM, Roy Lyseng wrote:
Unfortunately, 4 bits is too small for a time-zone specification
(unless you allow maximum 16 timezones to be used ;) So a timestamp
WITH time zone probably has to go in more than 8 bytes.
I am not a fan of keeping TZ information as a deep part of the server.
The complexity of the Olson TZ database coding system and database is on
it's face evidence that TZ stuff should be data driven, external, and
part of presentation layers, not storage layers. Keep all dates inside
the db in UTC and be done with it.
I think that you may consider storing TZ information with the actual
datetime values, but given the following assumptions:
- You derive the actual TZ offset when the datetime value is created.
- You are certain that the TZ offset that you assign is correct.
The TZ value is then isolated from the complexity of the TZ database and
can be used for whatever purposes you find proper.
I think that those cases are:
1. default presentation of a datetime value
2. conversion between SQL data types.
Case 1 may be overruled by the user's current locale, and may thus not
be important.
Case 2 is perhaps more interesting if you seek standard compliance. E.g
if you CAST a datetime value into a DATE, according to the standard you
should consider the datetime's timezone value (today is 01-JAN-09 for me
but it may still be 31-DEC-08 for some locales.) But again, this
standard compliance is probably not very important.
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
