Just to add my 2 cents to this discussion as someone who's worked with mxDateTime for almost 15 years.
I think we all agree that users of an application want to input date/time data using their local time (which may very well not be the timezone of the system running the application). On output they want to see their timezone as well, for obvious reasons. Now timezones are by nature not strictly defined, they change very often in history and what's worse: there's no way to predict the timezone details for the future. In many places around the world, the government defines the timezone data and they keep on changing the aspects every now and then, support day light savings time, drop the support, remove timezones for their countries, add new ones, or simply shift to a different time zone. The only timezone data that's more or less defined is historic timezone data, but even there, different sources can give different data. What does this mean for the application ? An application doesn't care about the timezone of a point in date/time. It just wants a standard way to store the date/time and a reliable way to work with it. The most commonly used standard for this is the UTC standard and so it's become good practice to convert all date/time values in applications to UTC for storage, math and manipulation. Just like with Unicode, the conversion to local time of the user happens at the UI level. Conversion from input data to UTC is easy, given the available C lib mechanisms (relying on the tz database). Conversion from UTC to local time is more difficult, but can also be done using the tz database. The timezone information of the entered data or the user's locale is usually available either through the environment, a configuration file or a database storing the original data - both on the input and on the output side. There's no need to stick this information onto the basic data types, since the application will already know anyway. For most use cases, this strategy works out really well. There are some cases, though, where you do need to work with local time instead of UTC. One such case is the definition of relative date/time values, another related one, the definition of repeating date/time values. These are often defined by users in terms of their local time or relative to other timezones they intend to travel to, so in order to convert the definitions back to UTC you have to run part of the calculation in the resp. local time zone. Repeating date/time values also tend to take other data into account such as bank holidays, opening times, etc. There's no end to making this more and more complicated :-) However, these things are not in the realm of a basic type anymore. They are application specific details. As a result, it's better to provide tools to implement all this, but not try force design decisions onto the application writer (which will eventually get in the way). BTW: That's main reason why I have so far refused to add native timezone support to the mxDateTime data types and instead let the applications decide on what's the best way for their particular use case. mxDateTime does provide extra tools for timezone support, but doesn't get in the way. It has so far worked out really well. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 06 2012) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2012-07-17: Python Meeting Duesseldorf ... 41 days to go 2012-07-02: EuroPython 2012, Florence, Italy ... 26 days to go 2012-05-16: Released eGenix pyOpenSSL 0.13 ... http://egenix.com/go29 ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
