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