#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
connection.set_type_trans_out(
{'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
(kinterbasdb-3.2.win32-FB-1.0-py2.4.exe).

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
http://kinterbasdb.sourceforge.net/dist_docs/usage.htm;
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.)

[David S. Rushby]

Logged In: YES
user_id=414645

> 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:
http://sourceforge.net/forum/forum.php?thread_id=1565029&forum_id=30917

[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.