From mal at egenix.com Tue Nov 6 14:01:05 2012 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Nov 6 14:01:19 2012 Subject: [egenix-users] mx.DateTime gmtoffset gmtime DST messup In-Reply-To: References: Message-ID: <50990A11.8060803@egenix.com> Hi Fran?ois, thanks for reporting this. I've opened a ticket for it. Could you please let me know, whether the system is running in POSIX mode, e.g. >>> import mx.DateTime >>> mx.DateTime.POSIX 1 The calculation of the offset relies on the correctness of the mktime() C lib API in most parts, but since DST switching is always tricky, it's also possible that we made a mistake somewhere that only shows up during switching times. Looking at the code, I think I know why this is happening: mxDateTime checks the GMT offset by interpreting the given time as local time and using mktime() to calculate the offset at the given time. Now, when moving from DST to normal time, the hour 02:00-02:59 exists twice. mktime() appears to map that hour to the first run (still in DST timezone), which is why the offset is wrong during the second run through of that hour in local time. I'm not exactly sure how this could be fixed, since the time where the problem occurs is indeed ambiguous and mxDateTime has no way of knowing which hour the local time value is referring to. I'll have a closer look at the problem later this week. On 30.10.2012 11:09, Fran?ois Meyer wrote: > Hi, > > I ran through a weird problem with mx.DateTime > during last DST switch on CET on sunday 2012-10-28 01:00 UTC. > > CET is on DST at UTC+2 up to 2012-10-18 01:00 UTC, then switches to UTC+1. > > In fact, for one hour past the switch, gmtoffset remained > stuck at +2 instead of +1. > > The machine monitors a timing system, the monitoring is driven by a python script, and it needs TZ > info. I ran through the problem looking at the logs during the night of the switch from DST. > > The logs are a bit verbose so I reproduce a simplified version of what happenned on another machine > ; this tiny script is ran on a Ubuntu 12.04.1, system time is UTC. > > #!/usr/bin/python > from mx import DateTime > from time import sleep > t=DateTime.now() > while 1: > print "------------------------------------------------" > print "t = DateTime.now() : ", t > print "t.gmtoffset ", t.gmtoffset() > print "t.gmtime ", t.gmtime() > sleep(5) > > I will set time on the machine, run this script on CET timezone > and see what happens around the switch date (20121028 01:00 UTC). > > 1st test, close to what really happened : > > I first set system (UTC) time at 2012-10-27 23:59, and check, I get that : > > root@ganymede:~# date -s"20121027 23:59"; date; TZ=CET date; > Sat Oct 27 23:59:00 UTC 2012 > Sat Oct 27 23:59:00 UTC 2012 > Sun Oct 28 01:59:00 CEST 2012 > > then I run the script, in CET timezone : > > fm@ganymede:~$ TZ=CET ./test_tz.py > t = DateTime.now() : 2012-10-28 01:59:00.04 > t.gmtoffset 02:00:00.00 > t.gmtime 2012-10-27 23:59:00.04 > > There all is ok. Two minutes later : > > ------------------------------------------------ > t = DateTime.now() : 2012-10-28 02:01:08.90 > t.gmtoffset 02:00:00.00 > t.gmtime 2012-10-28 00:01:08.90 > > still ok (but see further ref [1] in the text) > > One hour later, one minute before the switch : > > ------------------------------------------------ > t = DateTime.now() : 2012-10-28 02:59:01.80 > t.gmtoffset 02:00:00.00 > t.gmtime 2012-10-28 00:59:01.80 > > Still ok > > One minute later, after the switch : > > ------------------------------------------------ > t = DateTime.now() : 2012-10-28 02:00:01.86 > t.gmtoffset 02:00:00.00 > t.gmtime 2012-10-28 00:00:01.86 > > t is ok, > gmtoffset is bogus > gmtime is bogus, one hour back > > that situation lasts one hour : > > ------------------------------------------------ > t = DateTime.now() : 2012-10-28 02:59:59.65 > t.gmtoffset 02:00:00.00 > t.gmtime 2012-10-28 00:59:59.65 > > still bogus. > > ------------------------------------------------ > t = DateTime.now() : 2012-10-28 03:00:04.66 > t.gmtoffset 01:00:00.00 > t.gmtime 2012-10-28 02:00:04.66 > > back to normal. This is exactly the behaviour I observed in my logs. > > 2nd test : I first set the date 1 hour before the switch and check : > > root@ganymede:~# date -s"20121028 00:00"; date; TZ=CET date > Sun Oct 28 00:00:00 UTC 2012 > Sun Oct 28 00:00:04 UTC 2012 > Sun Oct 28 02:00:12 CEST 2012 > > Then I run the script, after setting TZ : > > fm@ganymede:~$ TZ=CET ./test_tz.py > t = DateTime.now() : 2012-10-28 02:01:31.54 > t.gmtoffset 01:00:00.00 > t.gmtime 2012-10-28 01:01:31.54 > > t is ok, but gmtoffset is wrong, and so does gmtime. > > So at the same system (UTC) time 20121028 00:01, DateTime gives two different > answers (in one case, the script has been launched on UTC 20121027, > DateTime gives correct result ref [1]; if the script is launched on UTC 20121028 00:00, > DateTime gives bogus results for gmtime and gmtoffset. > > This is not specific to CET, I tested with TZ=EST5DST : > > ------------------------------------------------ > t = DateTime.now() : 2012-11-04 01:59:59.25 > t.gmtoffset -04:00:00.00 > t.gmtime 2012-11-04 05:59:59.25 > > ------------------------------------------------ > t = DateTime.now() : 2012-11-04 01:00:04.26 > t.gmtoffset -04:00:00.00 > t.gmtime 2012-11-04 05:00:04.26 > > bogus, gmtime jumped backward, gmtoffset is wrong. > > ------------------------------------------------ > t = DateTime.now() : 2012-11-04 01:00:09.26 > t.gmtoffset -04:00:00.00 > t.gmtime 2012-11-04 05:00:09.26 > > and one hour later : > > ------------------------------------------------ > t = DateTime.now() : 2012-11-04 01:59:58.81 > t.gmtoffset -04:00:00.00 > t.gmtime 2012-11-04 05:59:58.81 > > Stil bogus and finally : > > ------------------------------------------------ > t = DateTime.now() : 2012-11-04 02:00:03.81 > t.gmtoffset -05:00:00.00 > t.gmtime 2012-11-04 07:00:03.81 > > back to normal, gmtime jumping one hour forward. > > (By the way, gmtime and gmtoffset two should read utctime and utcoffset). > > Any idea on what's going on ? > > Thank you in advance. > > Regards, > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > https://www.egenix.com/mailman/listinfo/egenix-users > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 06 2012) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: 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/ From fmeyer at obs-besancon.fr Tue Nov 6 16:09:10 2012 From: fmeyer at obs-besancon.fr (=?ISO-8859-15?Q?Fran=E7ois_Meyer?=) Date: Tue Nov 6 16:09:20 2012 Subject: [egenix-users] mx.DateTime gmtoffset gmtime DST messup In-Reply-To: <50990A11.8060803@egenix.com> References: <50990A11.8060803@egenix.com> Message-ID: On Tue, 6 Nov 2012, M.-A. Lemburg wrote: > Hi Fran?ois, > > thanks for reporting this. I've opened a ticket for it. > > Could you please let me know, whether the system is running > in POSIX mode, e.g. > >>>> import mx.DateTime >>>> mx.DateTime.POSIX > 1 Yep. Both the production system (debian 4.0) and the test system (ubuntu 12.04) report 1. > The calculation of the offset relies on the correctness > of the mktime() C lib API in most parts, but since DST > switching is always tricky, it's also possible that we made > a mistake somewhere that only shows up during switching > times. > > Looking at the code, I think I know why this is happening: > mxDateTime checks the GMT offset by interpreting the > given time as local time and using mktime() to calculate > the offset at the given time. > > Now, when moving from DST to normal time, the hour 02:00-02:59 > exists twice. mktime() appears to map that hour to the > first run (still in DST timezone), which is why the offset > is wrong during the second run through of that hour in local > time. > > I'm not exactly sure how this could be fixed, since the time > where the problem occurs is indeed ambiguous and mxDateTime > has no way of knowing which hour the local time value is > referring to. Yes. I had to clarify that in my head : clearly, you can allways unambiguously go from UTC to whatever timezone and DST status is, but the opposite is not true. This is an intrinsec ambiguity and in fact in my case, the proper way of dealing with it would be : 1. get system UTC time 2. deduce DST status and local CET time This is sound, but what I did is : 1. get local time 2. deduce UTC time and offset and this cannot be done unambiguously at least during DST switch. I checked that the python datetime package deals with that by distinguishing between "aware" and "naive" objects: http://docs.python.org/2/library/datetime.html Basically, if "naive", a datetime.utcoffset() will return None, and it would in my case. So the bottom line is that probably gmtoffset and gmtime should return an error or None in such situation. > I'll have a closer look at the problem later this week. > > On 30.10.2012 11:09, Fran?ois Meyer wrote: >> Hi, >> >> I ran through a weird problem with mx.DateTime >> during last DST switch on CET on sunday 2012-10-28 01:00 UTC. >> >> CET is on DST at UTC+2 up to 2012-10-18 01:00 UTC, then switches to UTC+1. >> >> In fact, for one hour past the switch, gmtoffset remained >> stuck at +2 instead of +1. >> >> The machine monitors a timing system, the monitoring is driven by a python script, and it needs TZ >> info. I ran through the problem looking at the logs during the night of the switch from DST. >> >> The logs are a bit verbose so I reproduce a simplified version of what happenned on another machine >> ; this tiny script is ran on a Ubuntu 12.04.1, system time is UTC. >> >> #!/usr/bin/python >> from mx import DateTime >> from time import sleep >> t=DateTime.now() >> while 1: >> print "------------------------------------------------" >> print "t = DateTime.now() : ", t >> print "t.gmtoffset ", t.gmtoffset() >> print "t.gmtime ", t.gmtime() >> sleep(5) >> >> I will set time on the machine, run this script on CET timezone >> and see what happens around the switch date (20121028 01:00 UTC). >> >> 1st test, close to what really happened : >> >> I first set system (UTC) time at 2012-10-27 23:59, and check, I get that : >> >> root@ganymede:~# date -s"20121027 23:59"; date; TZ=CET date; >> Sat Oct 27 23:59:00 UTC 2012 >> Sat Oct 27 23:59:00 UTC 2012 >> Sun Oct 28 01:59:00 CEST 2012 >> >> then I run the script, in CET timezone : >> >> fm@ganymede:~$ TZ=CET ./test_tz.py >> t = DateTime.now() : 2012-10-28 01:59:00.04 >> t.gmtoffset 02:00:00.00 >> t.gmtime 2012-10-27 23:59:00.04 >> >> There all is ok. Two minutes later : >> >> ------------------------------------------------ >> t = DateTime.now() : 2012-10-28 02:01:08.90 >> t.gmtoffset 02:00:00.00 >> t.gmtime 2012-10-28 00:01:08.90 >> >> still ok (but see further ref [1] in the text) >> >> One hour later, one minute before the switch : >> >> ------------------------------------------------ >> t = DateTime.now() : 2012-10-28 02:59:01.80 >> t.gmtoffset 02:00:00.00 >> t.gmtime 2012-10-28 00:59:01.80 >> >> Still ok >> >> One minute later, after the switch : >> >> ------------------------------------------------ >> t = DateTime.now() : 2012-10-28 02:00:01.86 >> t.gmtoffset 02:00:00.00 >> t.gmtime 2012-10-28 00:00:01.86 >> >> t is ok, >> gmtoffset is bogus >> gmtime is bogus, one hour back >> >> that situation lasts one hour : >> >> ------------------------------------------------ >> t = DateTime.now() : 2012-10-28 02:59:59.65 >> t.gmtoffset 02:00:00.00 >> t.gmtime 2012-10-28 00:59:59.65 >> >> still bogus. >> >> ------------------------------------------------ >> t = DateTime.now() : 2012-10-28 03:00:04.66 >> t.gmtoffset 01:00:00.00 >> t.gmtime 2012-10-28 02:00:04.66 >> >> back to normal. This is exactly the behaviour I observed in my logs. >> >> 2nd test : I first set the date 1 hour before the switch and check : >> >> root@ganymede:~# date -s"20121028 00:00"; date; TZ=CET date >> Sun Oct 28 00:00:00 UTC 2012 >> Sun Oct 28 00:00:04 UTC 2012 >> Sun Oct 28 02:00:12 CEST 2012 >> >> Then I run the script, after setting TZ : >> >> fm@ganymede:~$ TZ=CET ./test_tz.py >> t = DateTime.now() : 2012-10-28 02:01:31.54 >> t.gmtoffset 01:00:00.00 >> t.gmtime 2012-10-28 01:01:31.54 >> >> t is ok, but gmtoffset is wrong, and so does gmtime. >> >> So at the same system (UTC) time 20121028 00:01, DateTime gives two different >> answers (in one case, the script has been launched on UTC 20121027, >> DateTime gives correct result ref [1]; if the script is launched on UTC 20121028 00:00, >> DateTime gives bogus results for gmtime and gmtoffset. >> >> This is not specific to CET, I tested with TZ=EST5DST : >> >> ------------------------------------------------ >> t = DateTime.now() : 2012-11-04 01:59:59.25 >> t.gmtoffset -04:00:00.00 >> t.gmtime 2012-11-04 05:59:59.25 >> >> ------------------------------------------------ >> t = DateTime.now() : 2012-11-04 01:00:04.26 >> t.gmtoffset -04:00:00.00 >> t.gmtime 2012-11-04 05:00:04.26 >> >> bogus, gmtime jumped backward, gmtoffset is wrong. >> >> ------------------------------------------------ >> t = DateTime.now() : 2012-11-04 01:00:09.26 >> t.gmtoffset -04:00:00.00 >> t.gmtime 2012-11-04 05:00:09.26 >> >> and one hour later : >> >> ------------------------------------------------ >> t = DateTime.now() : 2012-11-04 01:59:58.81 >> t.gmtoffset -04:00:00.00 >> t.gmtime 2012-11-04 05:59:58.81 >> >> Stil bogus and finally : >> >> ------------------------------------------------ >> t = DateTime.now() : 2012-11-04 02:00:03.81 >> t.gmtoffset -05:00:00.00 >> t.gmtime 2012-11-04 07:00:03.81 >> >> back to normal, gmtime jumping one hour forward. >> >> (By the way, gmtime and gmtoffset two should read utctime and utcoffset). >> >> Any idea on what's going on ? >> >> Thank you in advance. >> >> Regards, >> >> >> >> _______________________________________________________________________ >> eGenix.com User Mailing List http://www.egenix.com/ >> https://www.egenix.com/mailman/listinfo/egenix-users >> > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Nov 06 2012) >>>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > > ::: 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/ > -- Fran?ois Meyer Tel : (+33) 3 81 66 69 27 Mob : 6 27 28 56 83 Observatoire de Besancon - BP1615 - 25010 Besancon cedex - FRANCE Institut UTINAM * Universite de Franche-Comte * CNRS UMR 6213 *** From joel at debian.org Sun Nov 25 20:27:11 2012 From: joel at debian.org (Joel Rosdahl) Date: Sun Nov 25 20:27:18 2012 Subject: [egenix-users] mx.DateTime.DateTimeDelta.pytimedelta() segfaults Message-ID: Hi, Reported by a Debian user (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664686): An mx.DateTimeDelta object created with DateTimeDeltaFrom() crashes on pytimedelta() call. For example: $ python Python 2.7.2+ (default, Nov 30 2011, 19:22:03) [GCC 4.6.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mx.DateTime >>> t = mx.DateTime.DateTimeDeltaFrom("3 hours") >>> t >>> t.absvalues() (0, 10800.0) >>> t.pytimedelta() Segmentation fault Reported on mxBase 3.2.1 but crashes on 3.2.4 as well. Regards, -- Joel (Debian package maintainer) From mal at egenix.com Sun Nov 25 20:40:37 2012 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Nov 25 20:40:45 2012 Subject: [egenix-users] mx.DateTime.DateTimeDelta.pytimedelta() segfaults In-Reply-To: References: Message-ID: <50B27435.8090702@egenix.com> Hi Joel, thanks for reporting the bug. We are able to reproduce this on our systems, so will investigate and then get back to you. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 25 2012) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: 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/ On 25.11.2012 20:27, Joel Rosdahl wrote: > Hi, > > Reported by a Debian user > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664686): > > An mx.DateTimeDelta object created with DateTimeDeltaFrom() crashes on > pytimedelta() call. For example: > > $ python > Python 2.7.2+ (default, Nov 30 2011, 19:22:03) > [GCC 4.6.2] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.DateTime > >>> t = mx.DateTime.DateTimeDeltaFrom("3 hours") > >>> t > > >>> t.absvalues() > (0, 10800.0) > >>> t.pytimedelta() > Segmentation fault > > Reported on mxBase 3.2.1 but crashes on 3.2.4 as well. > > Regards, > -- Joel (Debian package maintainer) > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > https://www.egenix.com/mailman/listinfo/egenix-users > From mal at egenix.com Sun Nov 25 20:50:14 2012 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Nov 25 20:50:22 2012 Subject: [egenix-users] mx.DateTime.DateTimeDelta.pytimedelta() segfaults In-Reply-To: <50B27435.8090702@egenix.com> References: <50B27435.8090702@egenix.com> Message-ID: <50B27676.8050403@egenix.com> On 25.11.2012 20:40, M.-A. Lemburg wrote: > Hi Joel, > > thanks for reporting the bug. We are able to reproduce this on our > systems, so will investigate and then get back to you. Turns out this is caused by the lazy import of the datetime module we're using in mxDateTime. The .pytimedelta() method doesn't make sure the module is already loaded. Here's a quick work-around: # Force import and setup of the datetime module in mxDateTime from mx.DateTime import Date Date(2012,11,25).pydate() This only has to be done once in the application (but should of course happen automatically in mxDateTime). After the call to .pydate() the datetime module is setup and ready to be used by mxDateTime and all subsequent calls to the methods succeed without segfaults. We'll release version 3.2.5 next week to address this bug. Thanks for the report, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 25 2012) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: 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/ From mal at egenix.com Wed Nov 28 11:33:44 2012 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Nov 28 11:35:32 2012 Subject: [egenix-users] ANN: eGenix mx Base Distribution 3.2.5 (mxDateTime, mxTextTools, etc.) Message-ID: <50B5E888.9080404@egenix.com> ________________________________________________________________________ ANNOUNCING eGenix.com mx Base Distribution Version 3.2.5 for Python 2.4 - 2.7 Open Source Python extensions providing important and useful services for Python programmers. This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/eGenix-mx-Base-Distribution-3.2.5-GA.html ________________________________________________________________________ ABOUT The eGenix.com mx Base Distribution for Python is a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed data types. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. Contents of the distribution: * mxDateTime - Easy to use Date/Time Library for Python * mxTextTools - Fast Text Parsing and Processing Tools for Python * mxProxy - Object Access Control for Python * mxBeeBase - On-disk B+Tree Based Database Kit for Python * mxURL - Flexible URL Data-Type for Python * mxUID - Fast Universal Identifiers for Python * mxStack - Fast and Memory-Efficient Stack Type for Python * mxQueue - Fast and Memory-Efficient Queue Type for Python * mxTools - Fast Everyday Helpers for Python The package also include a number of helpful smaller modules in the mx.Misc subpackage, such as mx.Misc.ConfigFile for config file parsing or mx.Misc.CommandLine to quickly write command line applications in Python. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. For more information, please see the distribution page: http://www.egenix.com/products/python/mxBase/ ________________________________________________________________________ NEWS The 3.2.5 release of the eGenix mx Base Distribution is the latest release of our open-source Python extensions. The new patch-level version includes a few important fixes: * Fixed a compatibility problem with Python 2.7.3 on Mac OS X 10.6 and later: Removed mx_customize_compiler() in favor of the standard distutils customize_compiler(). It now installs fine again with pip on more recent Mac OS X versions. Thanks to Leonardo Santagada for bringing this problem to our attention. * mxDateTime: Fixed a possible segfault in mxDateTime that was caused by the lazy datetime module import mechanism not catching all cases where the C API was used in mxDateTime. Thanks to Joel Rosdahl for bringing this to our attention. * Fixed a bug in the mx.Misc.CSV.Reader.objects() method, which triggered a TypeError. If you are upgrading from eGenix mx Base 3.1.x, please also see the eGenix mx Base Distribution 3.2.0 release notes for details on what has changed and which new features are available: http://www.egenix.com/company/news/eGenix-mx-Base-Distribution-3.2.0-GA.html As always, we are providing pre-built binaries for all common platforms: Windows 32/64-bit, Linux 32/64-bit, FreeBSD 32/64-bit, Mac OS X 32/64-bit. Source code archives are available for installation on all other Python platforms, such as Solaris, AIX, HP-UX, etc. To simplify installation in Zope/Plone and other egg-based systems, we have also precompiled egg distributions for all platforms. These are available on our own PyPI-style index server for easy and automatic download. Whether you are using a pre-built package or the source distribution, installation is a simple "python setup.py install" command in all cases. The only difference is that the pre-built packages do not require a compiler or the Python development packages to be installed. For a full list of changes, please refer to the eGenix mx Base Distribution change log at http://www.egenix.com/products/python/mxBase/changelog.html and the change logs of the various included Python packages. ________________________________________________________________________ DOWNLOADS The download archives and instructions for installing the packages can be found on the eGenix mx Base Distribution page: http://www.egenix.com/products/python/mxBase/ ________________________________________________________________________ LICENSE The eGenix mx Base package is distributed under the eGenix.com Public License 1.1.0 which is an Open Source license similar to the Python license. You can use the packages in both commercial and non-commercial settings without fee or charge. The package comes with full source code ________________________________________________________________________ SUPPORT Commercial support for this product is available from eGenix.com. Please see http://www.egenix.com/services/support/ for details about our support offerings. Enjoy, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 28 2012) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: 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/