Changes from 3.2.3 to 3.2.4
Fixed a possible double deallocation in the mxDateTime C API
import helper. Thanks to Daniele Varrazzo for reporting this.
Changes from 3.2.2 to 3.2.3
Fixed a possible segfault when using the .pydate(), .pydatetime()
and .pytime() methods. Thanks to Daniel Szoska for reporting
this.
Changes from 3.2.1 to 3.2.2
mxDateTime seconds rounding is now more careful to not show
60.00 or 61.00 as second value.
mxDateTime will now correctly work with numeric arrays (numpy)
again. Thanks to Christian Marquardt for reporting the problem.
mxDateTime's DateTimeFromAbsDateTime() now accepts leap second
values (86400.0 - <86401.0) as well. Thanks to Christian
Marquardt for reporting the problem.
mxDateTime range errors did not always format the wrong value.
Made mxDateTime compile again on Python 2.1 and 2.2.
Changes from 3.2.0 to 3.2.1
Fixed a segfault when comparing DateTime/DateTimeDelta with
None objects. Thanks to Mark Matthews for reporting this.
Changes from 3.1.2 to 3.2.0
Added new .rebuild() methods to both DateTime and DateTimeDelta
objects, making it easier creating new objects from existing
ones by just replacing some of the parameters (akin to the
mxURL .rebuild() method).
Greatly enhanced the interoperability with the Python datetime
module objects:
Added support for handling mixed type operations with
datetime.time objects.
Added new constructor methods to DateTime and DateTimeDelta
objects which aid in combining them with Python datetime
module objects: .pytime(), .pytimedelta(), .pydatetime()
and .pydate() as appropriate.
Added support for Python datetime module objects to the
generic mxDateTime constructors DateTimeFrom(), DateFrom(),
DateTimeDeltaFrom() (and their aliases).
The Python datetime module's C API is now loaded on demand
whenever mxDateTime needs to work with PyDateTime objects.
mxDateTime was updated to use mixed type number slots, a
feature which was added to Python in version 2.1 (by the
author of mxDateTime, Marc-André Lemburg). This has made
working with DateTime and DateTimeDelta objects and other
date/time types a lot more orbust.
mxDateTime's gmtime() now also works for ticks values beyond
2038 on 32-bit platforms that implement a POSIX confirm gmtime(),
but cannot handle post 2038 dates due to data type restrictions,
e.g. older 32-bit Linux platforms. As side-effect, this also
speeds up the gmtime() implementation on all platforms with
POSIX conform date/time handling.
mxDateTime will try to use the most accurate clock available
on the system for now(). For most POSIX systems, this is a
nanosecond resolution clock. A new global now_resolution allows
checking the resolution reported by the system. The performance
of now() was enhanced by directly interfacing to the various
platform C APIs.
Changed: mxDateTime will now format the seconds value in the
repr() and the str() output rounded to two decimal places. In
previous versions, it used to truncate the fraction after two
decimal places.
Known problem: mxDateTime doesn't build on FreeBSD with Python
2.7 and 2.7.1. This is a known problem with Python 2.7 and will
be fixed in Python 2.7.2. See http://bugs.python.org/issue10547
for details.
DateTimeFrom() now accepts a defaultdate parameter when parsing
strings or keyword-only arguments. defaultdate provides the
defaults to assume when pars of the date/time are not given.
It defaults to today().
DateFrom() will now only parse the date parts of a string and
only accept date-related keyword arguments.
Fixed a bug in the mxDateTime parser that triggered with some
ISO formats using second fractions. Thanks to Francesco
Pierfederici for bringing this to our attention.
Added support for more US AM/PM date formats such as "5:08pm"
(without space), "5:08 p.m." (with additional dots) to the
mxDateTime parser. Thanks to Tom at TicketStumbler for bringing
this to our attention.
Changed C API: mxDateTime now uses C longs for years internally
and in the C API. Note that the published C API has changed
because of this: mxDateTime.DateTime_FromDateAndTime() now
expects a long as year instead of an int. This change will
require a recompile of the applications using the mxDateTime
C API, but should only be noticeable on 64-bit platforms.
Added new C API DateTime_FromAbsDateTime to the mxDateTime C
API.
Added version number to C API object: Due to the changes in
the C API, the name of the C API object "mxDateTimeAPI" was
changed to "mxDateTimeAPI2", so that applications relying on
the old API don't import the changed API by accident.
Added optional calendar parameter to DateTimeFromAbsDateTime().
This allows creating DateTime instances with a given calendar.
Default is to use the Gregorian calendar.
Added BST to mx.DateTime.Timezone.
Fixed problem with now() resolution on Windows. It now provides
millisecond resolution again.
Fixed a bug in mx.DateTime.DateTimeFromAbsDateTime() which
caused an endless loop on 64-bit platforms for very large year
values.
Fixed Debian bug#494792: Incorrect subtraction with regular
Python datetime. This was actually a side-effect of the coercion
logic previously used in mxDateTime and not really a bug. The
new mixed type number slot implementations made it possible
to Darko Zurman for pointing this out.
Removed left-over debug code which caused the builtin strptime()
never to get used. Thanks to Alok Singhal for this one.
Fixed a bug in the mxDateTime .ticks() method which causes it
to raise an error for vahe Epoch.
on some platforms that lacked shared library support in the past. The
list hasn't been maintained at all and the gain is very limited, so just
get rid of it.
- assume that Python 2.4 and 2.5 are compatible and allow checking for
fallout.
- remove PYTHON_VERSIONS_COMPATIBLE that are obsoleted by the 2.3+
default. Modify the others to deal with the removals.
developer is officially maintaining the package.
The rationale for changing this from "tech-pkg" to "pkgsrc-users" is
that it implies that any user can try to maintain the package (by
submitting patches to the mailing list). Since the folks most likely
to care about the package are the folks that want to use it or are
already using it, this would leverage the energy of users who aren't
developers.
compatibility is maintained afaict, except an additional "mx" prefix
in the namespace
-make it a "distutils" pkg, so it works with Python-2.2.x
-license change - now freely redistibutable
extension Makefile fragments, because they really don't have anything to
do with the buildlink[12] frameworks. Change all the Makefiles that use
application.buildlink.mk and extension.buildlink.mk to use application.mk
and extension.mk instead.
