#68 TIMESTAMP out translator given wrong size tuple

Anders J. Munch

The timestamp out type translator is passed a
seven-tuple instead of a six-tuple. That is, after
{'TIMESTAMP': TypeTransTimestampOut} )
the argument passed to TypeTransTimestampOut is a tuple
containing seven values. The first six values are as
expected, the last one is 0.

I'm fairly confident this was introduced with an
upgrade, from 3.1
(kinterbasdb-3.1_pre9.win32-FB-1.0-py2.4.exe) to 3.2.0

Personally I don't care if you fix it or document the
change. The last value is milliseconds or what?

Relatedly, there's a little documentation bug in the
table "Signature Specifications for Input and Output
Translators" in
it goes "Args: a single Python 3-tuple of the form
(year, month, day, hour, minute, second)". That's a
big 3-tuple :-).

(W2K, Python 2.4.3, kinterbasdb 3.2.0, IB 7.1.)


  • Logged In: YES

    > The timestamp out type translator is passed a
    > seven-tuple instead of a six-tuple.

    That's due to a backward-incompatible (but deliberate)
    change that took place in the 3.2 development cycle, and is
    listed in docs/changelog.txt in the
    "BACKWARD-INCOMPATIBILITIES" section of "3.2rc1 versus
    3.2b1". Here's the text:
    Dynamic Type Translators for TIME and TIMESTAMP fields must
    now accomodate an additional tuple element: an integer
    which represents microseconds. The official TIME and
    TIMESTAMP type translators in typeconv_datetime_naked.py,
    typeconv_datetime_stdlib.py, and typeconv_datetime_mx.py
    have been updated, and can be used as a guide.

    Normally, I try to avoid significant
    backward-incompatibilities, but in this case, I couldn't
    think of a good alternative. Firebird timestamp and time
    fields contain an undocumented sub-second portion, which I
    was completely unaware of until someone pointed it out to me
    during the 3.2 development cycle. KInterbasDB had never
    supported it before, and I think that was a major limitation
    that needed to be fixed.

    Although it would have been possible to make the the
    microseconds tuple element optional, that would have imposed
    additional overhead on all of the standard conversions,
    which probably handle 99.7% of all consersions in
    KInterbasDB client programs. Also, making the microseconds
    element optional would have allowed those who write their
    own converters to remain unaware that a sub-second component
    is now available.

    So I decided to make a backward-incompatible change. I
    documented it in the changelog, but you're quite correct
    that I failed to update the Usage Guide. I'm sorry about
    that. When making a backward-incompatible change, I should
    have been more diligent about updating the documentation.
    The problem is now fixed in the online copy Usage Guide
    (http://kinterbasdb.sourceforge.net/dist_docs/usage.html ),
    and that fix will of course appear in KInterbasDB 3.2.1.

    > Relatedly, there's a little documentation bug in the
    > table "Signature Specifications for Input and Output
    > Translators"...
    > That's a big 3-tuple :-).

    I corrected that too.

    Thanks for reporting these documentation bugs.


    Since you're using Interbase 7.x, you might also be
    interested in a small compatibility update related to
    handling Interbase boolean fields:

    • assigned_to: nobody --> woodsplitter
    • status: open --> open-fixed
  • Russell Stuart
    Russell Stuart

    I struck this too. However I didn't think it was a bug - just a non backward compatible new feature.

    However, the reason I his it is because the two "standard" typeconv_datetime's seem to think it is in my interest to do timezone conversion. This drives me nuts. If I write a datetime.datetime(2008, 11, 27, 1, 2, 3) I expect some other program written in a different language on a different machine in a different timezone to read 2008-11-27T01:02:03, not some other value.

    This was easy enough to get around, just write your own converters for TIMESTAMP. Only now my program is not portable because of the tuple size problem.

    A request: could you please provide a implementation of TIMESTAMP converter using datetime.datetime that does not change the value being written. It is trivial to do, and means I will never have this problem again.