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.
The use cases I have encountered, many times, are:
(1) Single-time-zone micro-applications: when the user doesn't want to
be bothered with time zones because they're 100% in a single time zone.
These users want "Timestamp Ignoring Time Zone" where timestamps are
treated like they are always in UTC.
(2) Multiple-time-zone applications, where each user wants to see the
data in their *own* time zone. In this case, the *client protocol or
driver* should accept timestamps with time zones, convert them to UTC,
and store them. On retrieval, the timestamps should again be converted
by the client/driver into the local time zone of the user, unless the
user asks for the timestamp in some other time zone.
In neither case does it make any sense to store the "recorded" time zone
in the database.
Some of you will find the above timestamp logic quite familiar from
another database product. I am biased towards that implementation
because I helped develop it, based directly on my development of 3
different calendaring applications.
--Josh
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
