hi list readers,
I've been discussing the topic with Chris on the pygres list, but I
agree with him that this list is more indicated.
conversion to different formats: ticks (unity?, start time?), strings
(too many formats are possible), tuples (what does each item mean?
how many items?), stdlib datetime, mx.DateTime, other datetime
library...
right, we can't possibly be exhaustive, and this is just a particular
case of data conversion...
actually, I think that this problem is a bit different than specifying
translations for other types. the problem lies, as I see it, in the fact
that the dbengine will return datetime values in different string formats
depending on the setting of some datestyle within the engine, and that
this format may, in principle, be changed even between different fetchone
calls on the same query. so on one hand I agree that one would need to
think about a general solution to the problem of translating data from and
to the database not only for datetime data, but on the other hand I see
an extra complication in this specific case, which produces the impression
that this is an extremely complex problem even in the general case.
I don't really want to think about the general case, in this particular
one, what I would like to do is this:
distinguish the three types: date, datetime/timestamp, time/timedelta.
... what about offering ticks (seconds from the start of unix time or
difference in seconds between dates) and tuples [datetime: (year, month,
day, hour, minute, seconds.decimals), date: (year, month, day), timedelta:
(days, seconds.decimals)]?
well, in the solution I'm thinking about type information takes a
crucial role. data *coming* from the database keeps type information
with itself, so that one can translate it in the desired way (a STRING
"2003-05-12" is not the same as a DATE "2003-05-12" and the two things get
potentially translated in a different way (I'm having problems on this
point with the sqlite engine, which has no internal datetime types)).
but then also data *going* to the database must be clearly typed.
reserving a 6 elements tuple to represent a timestamp or a two elements
tuple for a timedelta may sound reasonable to us now, but could sound
as nonsense to someone working with complex numbers or some strange
mathematical entities, as well as with dates...
you could think about a totally different approach, where data going
into a specifically typed field gets translated in its own way, so a
float going to a timestamp gets a different treatment than a float going
to a number or to a date. leave alone the fact that datetime data in a
query is not necessarily associated to a table field.
I think that the strong dynamic typing in Python makes the first approach
natural and the second undesirable (actually a nightmare I think).
what I propose is that we only offer clearly typed data translation
from and to the database (support of two or more datetime modules)
or no translation at all (crude string representation).
I would also split the translation of data from the database to a
datetime module in two parts. one where the interface module produces
a tuple of float or integer values using the data from the database and
a second which translates these tuples into the correct datetime type.
this second part would be caracteristic of the datetime module and
could possibly be shared among the different interface modules.
if a module wants to represent datetime data as tuples, I don't see the
problem, as long as there is a distinct type for this.
curious about the reactions from the list...
regards,
Mario
--
... hinc sequitur, unamquamque rem naturalem tantum iuris ex natura habere,
quantum potentiae habet ad existendum et operandum ...
-- Baruch de Spinoza, TRACTATUS POLITICUS
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
