From bac@ivc.com Tue Mar 3 20:10:25 1998 From: bac@ivc.com (Brad Crittenden) Date: Tue, 03 Mar 1998 15:10:25 -0500 Subject: [DB-SIG] DbiDate testing for None Message-ID: <199803032010.PAA01937@ivc1.ivc.com> hi: i recently ran into the problem where testing for None for a DbiDate object causes a segfault. i searched the net and found a post on 3/17/97 regarding the problem but have seen no followup. I'm currently avoiding the problem by testing "type(x) is not NoneType". does anyone know of a solution or better work-around? thanks, brad problem: i discovered the segfault problem using filter(None,list) where an element of list was a DbiDate object. as shown below. also, "if d:" causes segfault when d is a DbiDate. >>> t.cur.execute(sql) >>> d=t.cur.fetchone() >>> t.cur.description [('PKEY', 'NUMBER', 40, 22, 38, 0, 0), ('DATECLOSED', 'DATE', 75, 7, 0, 0, 1)] >>> d (16, ) >>> filter(None,d) Segmentation Fault(coredump) this happens on solaris using oracledb and on NT4.0 (pythonwin and python) using odbc. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From js@ac-copy.com Wed Mar 4 12:01:42 1998 From: js@ac-copy.com (js@ac-copy.com) Date: Wed, 4 Mar 1998 13:01:42 +0100 Subject: [DB-SIG] DbiDate testing for None Message-ID: <199803041201.NAA08156@ns.ac-copy.com> |hi: | |i recently ran into the problem where testing for None for a DbiDate object |causes a segfault. i searched the net and found a post on 3/17/97 |regarding the problem but have seen no followup. I'm currently avoiding |the problem by testing "type(x) is not NoneType". does anyone know of a |solution or better work-around? | | |this happens on solaris using oracledb and on NT4.0 (pythonwin and python) |using odbc. | This also happens on linux with adabas using mxODBC. Mit freundlichen Grüßen Joachim Schmitz +------------------------------------------------------------------------+ | AC COPY IfD GmbH Telefon: 49-2404-908390 | | Joseph-von-Fraunhofer-Straße 3d FAX: 49-2404-908399 | | D-52477 Alsdorf e-Mail: js@ac-copy.com | | http://www.ac-copy.com ftp://ftp.ac-copy.com | +------------------------------------------------------------------------+ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Wed Mar 4 15:36:46 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Wed, 04 Mar 1998 16:36:46 +0100 Subject: [DB-SIG] DbiDate testing for None References: <199803041201.NAA08156@ns.ac-copy.com> Message-ID: <34FD750E.3624B066@uni-duesseldorf.de> perry@ns.ac-copy.com wrote: > > |hi: > | > |i recently ran into the problem where testing for None for a DbiDate object > |causes a segfault. i searched the net and found a post on 3/17/97 > |regarding the problem but have seen no followup. I'm currently avoiding > |the problem by testing "type(x) is not NoneType". does anyone know of a > |solution or better work-around? > | > | > |this happens on solaris using oracledb and on NT4.0 (pythonwin and python) > |using odbc. > | > > This also happens on linux with adabas using mxODBC. > Ouchh. This nb_nonzero-slot of the numeric protocol is not NULL checked when doing a PyObject_IsTrue()-call with a DateTime instance: that's what causes it to fail for mxODBC. I'll provide that slot in the next release of mxDateTime. Since you only wanted to check for None, this method might help: value,date = c.fetchone() if date is None: print 'Now what... ?' else: print 'OK' It avoids the 'is true' check (it only checks for identity which works in this case since None is a singleton). PS: Could it be that the odbc DbiDate has the same problem ? -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From js@ac-copy.com Wed Mar 4 16:31:46 1998 From: js@ac-copy.com (js@ac-copy.com) Date: Wed, 4 Mar 1998 17:31:46 +0100 Subject: [DB-SIG] DbiDate testing for None Message-ID: <199803041631.RAA10738@ns.ac-copy.com> |> |> This also happens on linux with adabas using mxODBC. |> | |Ouchh. This nb_nonzero-slot of the numeric protocol is not NULL |checked when doing a PyObject_IsTrue()-call with a DateTime |instance: that's what causes it to fail for mxODBC. | |I'll provide that slot in the next release of mxDateTime. |Since you only wanted to check for None, this method might |help: | |value,date = c.fetchone() |if date is None: | print 'Now what... ?' |else: | print 'OK' | |It avoids the 'is true' check (it only checks for identity |which works in this case since None is a singleton). | |PS: Could it be that the odbc DbiDate has the same problem ? | There seem to be some serious memory problems with mxODBC and DbiDate. unfortunately I can't include an example cause it's part of a large program, but here is the code fragment: self.cursor.execute(queryst,tuple(data)) self.db.commit() print self.table,str(self.addmes) self.dialog = Pmw.MessageDialog(self.parent, title = 'Add Info', text = "Record in " + self.table + " hinzugefügt", bitmap = 'info', command = self.addmes, buttons = (AddMode_c,BrowseMode)) This works with the printstatement uncommented, when I comment it out, I get an error message from the Pmw.MessageDialog-call. Here is the querystring: insert into ImmoAuftrag( KundenNr, Verkaeufer, Auftrag_Nr, Angebot_Datum, Angebot_Betrag, Text_aus, Anz_Fotos, Auftrag_Datum, Auftrag_Betrag, Rechnung_Datum, Rechnung_Betrag, von, bis, Laufzeit, Bundesland, Rubrik_1, Rubrik_2, Rubrik_3, Region, PLZ, Ort, Text, Kontakt_Text, Kontakt_Telefon, Kontakt_Fax, Grafiken) values ( ?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) and here the data: ,Data: [31867, 'FA', '2082', '1998-03-04', 0.0, '', 0, None, 0.0, None, 0.0, None, None, 0, '', '', '', '', '', '', '', '', '', '', '', ''] Mit freundlichen Grüßen Joachim Schmitz +------------------------------------------------------------------------+ | AC COPY IfD GmbH Telefon: 49-2404-908390 | | Joseph-von-Fraunhofer-Straße 3d FAX: 49-2404-908399 | | D-52477 Alsdorf e-Mail: js@ac-copy.com | | http://www.ac-copy.com ftp://ftp.ac-copy.com | +------------------------------------------------------------------------+ -- |-- |Marc-Andre Lemburg | _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From js@ac-copy.com Thu Mar 5 12:53:18 1998 From: js@ac-copy.com (js@ac-copy.com) Date: Thu, 5 Mar 1998 13:53:18 +0100 Subject: [DB-SIG] DbiDate testing for None Message-ID: <199803051253.NAA21078@ns.ac-copy.com> Hello, I now changed the SQL-statement to insert the date value as DateTime-Instance, and now it works, without the print-statement. It also gave an error message when I inserted a date-value as dbiDate.timevalue. this time the error-message is: self.dialog = Pmw.MessageDialog(self.parent, title = 'Add Info', exceptions.AttributeError: __float__ I hope this provides some hints, where the cause may be. Mit freundlichen Grüßen Joachim Schmitz +------------------------------------------------------------------------+ | AC COPY IfD GmbH Telefon: 49-2404-908390 | | Joseph-von-Fraunhofer-Straße 3d FAX: 49-2404-908399 | | D-52477 Alsdorf e-Mail: js@ac-copy.com | | http://www.ac-copy.com ftp://ftp.ac-copy.com | +------------------------------------------------------------------------+ -- |From lemburg@uni-duesseldorf.de Wed Mar 4 19:35:21 1998 |Date: Wed, 04 Mar 1998 18:52:59 +0100 |From: "M.-A. Lemburg" |Organization: SCM: http://starship.skyport.net/~lemburg |To: js@ac-copy.com |Subject: Re: [DB-SIG] DbiDate testing for None | |perry@ns.ac-copy.com wrote: |> There seem to be some serious memory problems with mxODBC and DbiDate. |> unfortunately I can't include an example cause it's part of a large program, |> but here is the code fragment: |> |> self.cursor.execute(queryst,tuple(data)) |> self.db.commit() |> print self.table,str(self.addmes) |> self.dialog = Pmw.MessageDialog(self.parent, title = 'Add Info', |> text = "Record in " + self.table + " hinzugefügt", |> bitmap = 'info', |> command = self.addmes, |> buttons = (AddMode_c,BrowseMode)) |> |> This works with the printstatement uncommented, when I comment it out, I get |> an error message from the Pmw.MessageDialog-call. | |What does it say ? And what are self.table and self.addmes ? It could |be a reference count problem... | |> |> Here is the querystring: |[...] |> and here the data: |> |> ,Data: [31867, 'FA', '2082', '1998-03-04', 0.0, '', 0, None, 0.0, None, 0.0, |> None, None, 0, '', '', '', '', '', '', '', '', '', '', '', ''] |> | |-- |Marc-Andre Lemburg | | _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Fri Mar 6 12:42:06 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Fri, 06 Mar 1998 13:42:06 +0100 Subject: [DB-SIG] DateTime: Changing the time value handling ?! Message-ID: <34FFEF1E.3E9B46B8@uni-duesseldorf.de> For infos on DateTime, two types for date and time handling written in C, see: http://starship.skyport.net/~lemburg/mxDateTime.html Upon common request I am planning to change the behaviour of handling conversion from and to Unix ticks. It currently converts Unix ticks (the floats that time.time() returns) to UTC (aka GMT) for the broken down time representation (giving an output similar to time.gmtime()). Conversion from a DateTime instance to a ticks float is also done assuming the stored value being given in UTC (something like time.mktime for UTC values). Several users have complained about this not being very intuitive, so I'm considering adding new ways to do the conversion, e.g. provide a DateTimeFromLocalTime(1234.567) constructor and a .localtime() method. Conversion to a float will also use local time. Is that ok with you ? -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@exchange.microsoft.com Wed Mar 11 11:04:43 1998 From: gstein@exchange.microsoft.com (Greg Stein (Exchange)) Date: Wed, 11 Mar 1998 03:04:43 -0800 Subject: [DB-SIG] DateTime: Changing the time value handling ?! Message-ID: <69D8143E230DD111B1D40000F848584001E54277@ED> Why should Unix ticks be any different from the others? All of the times are absolute with respect to an unknown time zone. You have NOT picked any time zone. If you generate a ticks value, then somebody should use that with respect to the proper time zone. Generally, the only point where a time zone becomes apparent is when people use something like the .Format() method (or time.ctime()) and the output includes a time zone string. It sounds like people are mixing time zones values. e.g. they create a DateTime assuming it is within the current time zone, but then pass it to a function in the time module that expects a UTC time (or vice versa). A large part of the discussion has historically fallen around time zone handling. The unofficial consensus has always come out of that with "don't build time zone information into the base types" (let higher levels deal with it) I would highly recommend the absolute avoidance of anything that infers / implies time zones within the base data types. -g -----Original Message----- From: M.-A. Lemburg [SMTP:lemburg@uni-duesseldorf.de] Sent: Friday, March 06, 1998 4:42 AM To: Python Mainlist @ Python.Org Cc: DB-SIG @ Python.org Subject: [DB-SIG] DateTime: Changing the time value handling ?! For infos on DateTime, two types for date and time handling written in C, see: http://starship.skyport.net/~lemburg/mxDateTime.html Upon common request I am planning to change the behaviour of handling conversion from and to Unix ticks. It currently converts Unix ticks (the floats that time.time() returns) to UTC (aka GMT) for the broken down time representation (giving an output similar to time.gmtime()). Conversion from a DateTime instance to a ticks float is also done assuming the stored value being given in UTC (something like time.mktime for UTC values). Several users have complained about this not being very intuitive, so I'm considering adding new ways to do the conversion, e.g. provide a DateTimeFromLocalTime(1234.567) constructor and a .localtime() method. Conversion to a float will also use local time. Is that ok with you ? -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Wed Mar 11 11:32:32 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Wed, 11 Mar 1998 12:32:32 +0100 Subject: [DB-SIG] DateTime: Changing the time value handling ?! References: <69D8143E230DD111B1D40000F848584001E54277@ED> Message-ID: <35067650.E9B2C07@uni-duesseldorf.de> Greg Stein (Exchange) wrote: > > Why should Unix ticks be any different from the others? All of the times are > absolute with respect to an unknown time zone. You have NOT picked any time > zone. If you generate a ticks value, then somebody should use that with > respect to the proper time zone. > > Generally, the only point where a time zone becomes apparent is when people > use something like the .Format() method (or time.ctime()) and the output > includes a time zone string. > > It sounds like people are mixing time zones values. e.g. they create a > DateTime assuming it is within the current time zone, but then pass it to a > function in the time module that expects a UTC time (or vice versa). I would like to keep it the way it is as much as you do, but there is a problem with the C lib that makes the change necessary: conversion from a broken down time value given in UTC to a ticks value is not supported (a few OSes define timegm() for this). I can only convert from broken down values in local time to ticks using mktime() [the time module exposes the same flaw, BTW]. In previous versions I simply took that value and subtracted the timezone offset, but that fails whenever DST is active and it also forced me to copy code from the time module, which I can now avoid (gains some portablility and reduces maintenance overhead). Conversion from ticks to broken time is no problem. I use gmtime() and localtime() for those. > A large part of the discussion has historically fallen around time zone > handling. The unofficial consensus has always come out of that with "don't > build time zone information into the base types" (let higher levels deal > with it) I'm not building time zone *information* into the base type -- I only need to make an assumption for Unix ticks since the C lib API is missing. > I would highly recommend the absolute avoidance of anything that infers / > implies time zones within the base data types. Me too, but I currently don't see any alternative. It's only the conversion DateTime -> ticks that relies on the 'local time assumption'. Everything else is done in a time zone independant fashion. If you know a way around this, I'd be the first to implement it. -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From jim.fulton@digicool.com Wed Mar 11 13:51:08 1998 From: jim.fulton@digicool.com (Jim Fulton) Date: Wed, 11 Mar 1998 08:51:08 -0500 Subject: [DB-SIG] DateTime: Changing the time value handling ?! References: <69D8143E230DD111B1D40000F848584001E54277@ED> Message-ID: <350696CC.5366@digicool.com> Greg Stein (Exchange) wrote: > > Why should Unix ticks be any different from the others? All of the times are > absolute with respect to an unknown time zone. You have NOT picked any time > zone. If you generate a ticks value, then somebody should use that with > respect to the proper time zone. > > Generally, the only point where a time zone becomes apparent is when people > use something like the .Format() method (or time.ctime()) and the output > includes a time zone string. It also comes in to play when you do math on times. 9pm EST - 8pm PST is *not* one hour. These sorts of issues are important if you have to deal with times from multiple time zones, or use time data from one time zone in another. > It sounds like people are mixing time zones values. e.g. they create a > DateTime assuming it is within the current time zone, but then pass it to a > function in the time module that expects a UTC time (or vice versa). > > A large part of the discussion has historically fallen around time zone > handling. The unofficial consensus has always come out of that with "don't > build time zone information into the base types" (let higher levels deal > with it) The ODMG standard includes time zone in it's Time and Timestamp classes. They take a fairly minimalist approach. Their time zones are just offsets from UTC. They leave deciding *what* the offset is (e.g. dealing with daylight savings time) to the application. > I would highly recommend the absolute avoidance of anything that infers / > implies time zones within the base data types. I disagree with this statement, although not entirely. As I have said before, I think the Date-Time classes should be based on the ODMG standard which provides a *mimimalish*, but useful, treatment of time zones. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Wed Mar 11 14:40:05 1998 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Wed, 11 Mar 1998 09:40:05 -0500 Subject: [DB-SIG] DateTime: Changing the time value handling ?! In-Reply-To: Your message of "Wed, 11 Mar 1998 08:51:08 EST." <350696CC.5366@digicool.com> References: <69D8143E230DD111B1D40000F848584001E54277@ED> <350696CC.5366@digicool.com> Message-ID: <199803111440.JAA20981@eric.CNRI.Reston.Va.US> Dear db-sig posters, could you perhaps remove python-list@cwi.nl from the cc: list of this thread? --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Wed Mar 11 15:23:38 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Wed, 11 Mar 1998 16:23:38 +0100 Subject: [DB-SIG] DateTime: Changing the time value handling ?! References: <69D8143E230DD111B1D40000F848584001E54277@ED> <350696CC.5366@digicool.com> Message-ID: <3506AC7A.458131F@uni-duesseldorf.de> Jim Fulton wrote: > > Greg Stein (Exchange) wrote: > > > > The ODMG standard includes time zone in it's Time and Timestamp classes. > They take a fairly minimalist approach. Their time zones are just > offsets > from UTC. They leave deciding *what* the offset is (e.g. dealing with > daylight savings time) to the application. > > > I would highly recommend the absolute avoidance of anything that infers / > > implies time zones within the base data types. > > I disagree with this statement, although not entirely. As I have > said before, I think the Date-Time classes should be based on the > ODMG standard which provides a *mimimalish*, but useful, treatment > of time zones. I think Greg meant the low-level implementation of DateTime objects. Time zone handling classes can be built on top of the basic types, though it will certainly not be easy: there is no portable way of getting the DST start/stop information, since the C API doesn't export any of this information. For details on an approach that works on some Unixes, see the Julian package on www.python.org in the contributed section. There's also a tzparse.py file in the standard library that relies on the environment variable TZ. -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From jim.fulton@digicool.com Wed Mar 11 15:49:42 1998 From: jim.fulton@digicool.com (Jim Fulton) Date: Wed, 11 Mar 1998 10:49:42 -0500 Subject: [DB-SIG] DateTime: Changing the time value handling ?! References: <69D8143E230DD111B1D40000F848584001E54277@ED> <350696CC.5366@digicool.com> <3506AC7A.458131F@uni-duesseldorf.de> Message-ID: <3506B296.23E6@digicool.com> M.-A. Lemburg wrote: > > Jim Fulton wrote: > > > > Greg Stein (Exchange) wrote: > > > > > > > The ODMG standard includes time zone in it's Time and Timestamp classes. > > They take a fairly minimalist approach. Their time zones are just > > offsets > > from UTC. They leave deciding *what* the offset is (e.g. dealing with > > daylight savings time) to the application. > > > > > I would highly recommend the absolute avoidance of anything that infers / > > > implies time zones within the base data types. > > > > I disagree with this statement, although not entirely. As I have > > said before, I think the Date-Time classes should be based on the > > ODMG standard which provides a *mimimalish*, but useful, treatment > > of time zones. > > I think Greg meant the low-level implementation of DateTime objects. So did I. I think that the low-level data structure should store an *offset from UTC*. I thik that determination and interpretation of the offset should be left to the application. Of course, applications that don't care about the offset could ignore it. In my implementation of the ODMG Date, Time, Timestamp, and Interval classes (currently a low-priority project of mine), dates and times are stored as local time and an offset. Since the offset is optional, applications can ignore it, but it can be obtained by apps that care and is used in date-time arithmetic. I don't worry about "ticks" in my implementation, as I store date/time components directly, rather than as offsets from some time. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Wed Mar 11 17:14:45 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Wed, 11 Mar 1998 18:14:45 +0100 Subject: [DB-SIG] DateTime: Changing the time value handling ?! References: <69D8143E230DD111B1D40000F848584001E54277@ED> <350696CC.5366@digicool.com> <3506AC7A.458131F@uni-duesseldorf.de> <3506B296.23E6@digicool.com> Message-ID: <3506C685.65864FDA@uni-duesseldorf.de> Jim Fulton wrote: > > I think that the low-level data structure should store > an *offset from UTC*. I thik that determination and interpretation > of the offset should be left to the application. Of course, > applications that don't care about the offset could ignore it. > > In my implementation of the ODMG Date, Time, Timestamp, and Interval > classes (currently a low-priority project of mine), dates and > times are stored as local time and an offset. Since the offset > is optional, applications can ignore it, but it can be obtained by > apps that care and is used in date-time arithmetic. I don't worry > about "ticks" in my implementation, as I store date/time components > directly, rather than as offsets from some time. You'll have to worry about ticks and COM dates as soon as you have a need to interface to them. Even worse, rounding becomes a real problem too... When dealing with different time zones its better to have a set of specialized functions/classes. Time zone information is usually not stored together with date/time values. Most databases only work with broken down values and have no idea of the time zone the given values apply to. (And that's what I wrote the DateTime package for after all: to interface to databases ;-) -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From jim.fulton@digicool.com Wed Mar 11 18:14:00 1998 From: jim.fulton@digicool.com (Jim Fulton) Date: Wed, 11 Mar 1998 13:14:00 -0500 Subject: [DB-SIG] DateTime: Changing the time value handling ?! References: <69D8143E230DD111B1D40000F848584001E54277@ED> <350696CC.5366@digicool.com> <3506AC7A.458131F@uni-duesseldorf.de> <3506B296.23E6@digicool.com> <3506C685.65864FDA@uni-duesseldorf.de> Message-ID: <3506D468.48DC@digicool.com> M.-A. Lemburg wrote: > > When dealing with different time zones its better to have a > set of specialized functions/classes. Time zone information > is usually not stored together with date/time values. Most > databases only work with broken down values and have no idea > of the time zone the given values apply to. (And that's what > I wrote the DateTime package for after all: to interface to > databases ;-) ODMG stands for Object *Database* Management Group and the ODMG standard I keep refering to and that includes time zone in its Time and Timestamp classes is a *database* standard. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Wed Mar 11 20:26:20 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Wed, 11 Mar 1998 21:26:20 +0100 Subject: [DB-SIG] DateTime: Changing the time value handling ?! References: <69D8143E230DD111B1D40000F848584001E54277@ED> <350696CC.5366@digicool.com> <3506AC7A.458131F@uni-duesseldorf.de> <3506B296.23E6@digicool.com> <3506C685.65864FDA@uni-duesseldorf.de> <3506D468.48DC@digicool.com> Message-ID: <3506F36C.A0ACD09@uni-duesseldorf.de> Jim Fulton wrote: > > M.-A. Lemburg wrote: > > > > When dealing with different time zones its better to have a > > set of specialized functions/classes. Time zone information > > is usually not stored together with date/time values. Most > > databases only work with broken down values and have no idea > > of the time zone the given values apply to. (And that's what > > I wrote the DateTime package for after all: to interface to > > databases ;-) > > ODMG stands for Object *Database* Management Group and the ODMG > standard I keep refering to and that includes time zone in its > Time and Timestamp classes is a *database* standard. I know, but the database APIs, I'm familiar with, don't support any time zone specific data interchange. They simply return the broken down values you stored -- without doing any conversions or time zone checking. How would I store the time zone offset in those databases ? -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From jim.fulton@digicool.com Wed Mar 11 21:14:26 1998 From: jim.fulton@digicool.com (Jim Fulton) Date: Wed, 11 Mar 1998 16:14:26 -0500 Subject: [DB-SIG] DateTime: Changing the time value handling ?! References: <69D8143E230DD111B1D40000F848584001E54277@ED> <350696CC.5366@digicool.com> <3506AC7A.458131F@uni-duesseldorf.de> <3506B296.23E6@digicool.com> <3506C685.65864FDA@uni-duesseldorf.de> <3506D468.48DC@digicool.com> <3506F36C.A0ACD09@uni-duesseldorf.de> Message-ID: <3506FEB2.3F97@digicool.com> M.-A. Lemburg wrote: > > Jim Fulton wrote: > > > > M.-A. Lemburg wrote: > > > > > > When dealing with different time zones its better to have a > > > set of specialized functions/classes. Time zone information > > > is usually not stored together with date/time values. Most > > > databases only work with broken down values and have no idea > > > of the time zone the given values apply to. (And that's what > > > I wrote the DateTime package for after all: to interface to > > > databases ;-) > > > > ODMG stands for Object *Database* Management Group and the ODMG > > standard I keep refering to and that includes time zone in its > > Time and Timestamp classes is a *database* standard. > > I know, but the database APIs, I'm familiar with, don't support any time > zone specific data interchange. They simply return the broken down > values you stored -- without doing any conversions or time zone > checking. > How would I store the time zone offset in those databases ? I guess you don't. But that doesn't mean you shouldn't make it possible to handle the time zone (offset) in the underlying type. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Thu Mar 12 09:49:55 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Thu, 12 Mar 1998 10:49:55 +0100 Subject: [DB-SIG] DateTime: Changing the time value handling ?! References: <69D8143E230DD111B1D40000F848584001E54277@ED> <350696CC.5366@digicool.com> <3506AC7A.458131F@uni-duesseldorf.de> <3506B296.23E6@digicool.com> <3506C685.65864FDA@uni-duesseldorf.de> <3506D468.48DC@digicool.com> <3506F36C.A0ACD09@uni-duesseldorf.de> <3506FEB2.3F97@digicool.com> Message-ID: <3507AFC3.67D5B80F@uni-duesseldorf.de> Jim Fulton wrote: > > M.-A. Lemburg wrote: > > > > How would I store the time zone offset in those databases ? > > I guess you don't. But that doesn't mean you shouldn't make it > possible to handle the time zone (offset) in the underlying type. Hmm, I'll think about it. The offset should be declared as such though, e.g. a 0 offset wouldn't necessarily mean that you have UTC stored in your object. And the offset would probably only be used for arithmetic, so that the internals don't have to be touched. I think I'll try that as an experiment... (An offset in minutes should be ok; that'll result in an extra short, or 2 bytes, per object) -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From Paul.Boddie@cern.ch Fri Mar 13 17:25:05 1998 From: Paul.Boddie@cern.ch (Paul Boddie) Date: Fri, 13 Mar 1998 18:25:05 +0100 Subject: [DB-SIG] oracledb Stored Procedure Magic Message-ID: <199803131725.SAA03885@aisws5.cern.ch> Hello, After some time wondering whether there might one day be an implementation of stored procedure calls in implementations of the DB-API, I finally got round to modifying the oracledb module to do the necessary magic. Oracle seems to call stored procedures at the cursor level, ie. the context of a call is a cursor, not a connection, so I took the liberty of adding callproc to the cursorObject, and not the connectionObject. Actually, this is my first attempt at experimenting with Python extensions and Oracle Call Interface, so I took the easy way out and "re-used" a fair amount of the work done for the execute method, binding, and producing outputs. Whether it works in all cases, handles errors correctly, and doesn't leak memory, are all unaddressed issues. Who would be interested in seeing the patches for this? I would have attached them, but I suppose that for many people they are irrelevant. I have, however, provided them on a Web page: http://assuwww.cern.ch/~pboddie/Personal/Interests/Python/Patch_for_oracledb.html I would appreciate some feedback from those "in the know" concerning OCI, and Python extensions - if there is anyone reading this who might deal with both of them. Regards, Paul Boddie, CERN, Geneva, Switzerland _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Sat Mar 14 11:56:19 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Sat, 14 Mar 1998 12:56:19 +0100 Subject: [DB-SIG] DateTime: Changing the time value handling ?! References: <69D8143E230DD111B1D40000F848584001E54277@ED> <350696CC.5366@digicool.com> <3506AC7A.458131F@uni-duesseldorf.de> <3506B296.23E6@digicool.com> <3506C685.65864FDA@uni-duesseldorf.de> <3506D468.48DC@digicool.com> <3506F36C.A0ACD09@uni-duesseldorf.de> <3506FEB2.3F97@digicool.com> <3507AFC3.67D5B80F@uni-duesseldorf.de> Message-ID: <350A7063.5A97AA16@uni-duesseldorf.de> --------------7CF3CC331E9AD3E47ED3FB94 Content-type: text/plain; charset="us-ascii" M.-A. Lemburg wrote: > > Jim Fulton wrote: > > > > M.-A. Lemburg wrote: > > > > > > How would I store the time zone offset in those databases ? > > > > I guess you don't. But that doesn't mean you shouldn't make it > > possible to handle the time zone (offset) in the underlying type. > > Hmm, I'll think about it. The offset should be declared as such > though, e.g. a 0 offset wouldn't necessarily mean that you have > UTC stored in your object. And the offset would probably only be > used for arithmetic, so that the internals don't have to be touched. > > I think I'll try that as an experiment... > (An offset in minutes should be ok; that'll result in an extra > short, or 2 bytes, per object) Here are my findings: - including the offset in the basic type introduces too many complications - it's usage would not be transparent, e.g. some values might have an offset, some others don't; when you do calculations with them you suddenly get strange results and tracing these back is no fun at all - inventing new schemes on top of the two basic types *is* fun: I wrote a set of ODMG type classes that do handle offsets using the two basic types in some 20 minutes Conclusion: I'll leave the DateTime[Delta] as they are -- without hidden offsets (but with the change in the way ticks are handled). -- Marc-Andre Lemburg --------------7CF3CC331E9AD3E47ED3FB94 Content-type: text/plain; charset="us-ascii" """ ODMG type classes for date/time handling These are built on top of the basic types and include rudimentary time zone handling through an offset in minutes. It is the applications responsibility to set the offset to correct values. The offsets are then used in date calculations. The implementation has not yet been thoroughly tested, but provides a good example of the swiftness with which you can build new date/time classes on top of the two basic types. If you find any errors or would like to see new features, mail them to mal@lemburg.com. """ __version__ = '0.1alpha' __author__ = 'Marc-Andre Lemburg, mailto:mal@lemburg.com' import DateTime class _EmptyClass: pass class Date: offset = 0 # from some imaginary time zone in minutes def __init__(self,*args): self.data = apply(DateTime.DateTime,args) def set_timezone(self,offset): self.offset = offset def __getattr__(self,what): return getattr(self.data,what) def __sub__(self,other): if isinstance(other,Date): if self.offset != other.offset: # Be careful about different offsets: d = (self.data - self.offset * DateTime.oneMinute) \ - (other.data - other.offset * DateTime.oneMinute) else: # Offsets are equal: no adjustment needed d = self.data - other.data o = _EmptyClass() o.__class__ = Interval o.data = d return o elif isinstance(other,Interval): d = self.data - other.data o = _EmptyClass() o.__class__ = Date o.data = d o.offset = self.offset # inherit the offset return o else: raise TypeError,"operation not supported" def __add__(self,other): if isinstance(other,Interval): d = self.data + other.data o = _EmptyClass() o.__class__ = Date o.data = d o.offset = self.offset # inherit the offset return o else: raise TypeError,"operation not supported" def __str__(self): return str(self.data) def __repr__(self): return '' % (str(self.data),id(self)) class Timestamp(Date): def __repr__(self): return '' % (str(self.data),id(self)) class Time: def __init__(self,*args): self.data = apply(DateTime.TimeDelta,args) def __getattr__(self,what): return getattr(self.data,what) def __sub__(self,other): if isinstance(other,Time): d = self.data - other.data o = _EmptyClass() o.__class__ = Interval o.data = d return o elif isinstance(other,Interval): d = self.data - other.data o = _EmptyClass() o.__class__ = Time o.data = d return o else: raise TypeError,"operation not supported" def __add__(self,other): if isinstance(other,Time): d = self.data + other.data o = _EmptyClass() o.__class__ = Interval o.data = d return o elif isinstance(other,Interval): d = self.data + other.data o = _EmptyClass() o.__class__ = Time o.data = d return o else: raise TypeError,"operation not supported" def __str__(self): return str(self.data) def __repr__(self): return '