From gm@hl-technik.de Sun Oct 6 21:30:00 1996 From: gm@hl-technik.de (Georg Mischler) Date: Sun, 6 Oct 1996 19:30:00 -0100 Subject: [PYTHON DB-SIG] Sybase Module with ctlib for linux? Message-ID: <96Oct6.214144gmt-0100.20737@charon.hl-technik.de> Hello out there ... I just managed to compile the included demos together with Greg Thain's ELF converted open client libraries for sybase on my Linux box. (didn't check if they really work though yet ;) Next thing was trying to compile one of the several python sybase modules (The most recent one and most complete looking of them by Tim Docker with modifications by Thomas Palmer) - with little success. Although I link with every library file around (lacking other instructions with the source), I still get tons of undefined symbols in the end. What happens? Are those modules not meant to use the open client libraries at all? Does anything like this work on linux? Hard to imagine that there isn't any installation out there where someone accesses a sybase database engine from a python script on linux. Slowly beginning to feel really dumb... Any further information highly appreciated! -Georg Georg Mischler -- daylight&simulations -- mailto: gm@hl-technik.de HL-Technik AG -- consulting engineers -- http://www.hl-technik.de ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From tmb@best.com Thu Oct 10 15:26:43 1996 From: tmb@best.com (Thomas Breuel) Date: Thu, 10 Oct 1996 07:26:43 -0700 Subject: [PYTHON DB-SIG] SQL interface Message-ID: <199610101426.HAA02535@shellx.best.com> Hi, I was wondering what the status of the SQL database interface module for Python is. I checked the FTP site (ftp.python.org) but couldn't find anything. I need something fairly soon for interfacing with DB2 (the API is basically ODBC), and I'd rather not invent my own interface. Thanks, Thomas. ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From tmb@best.com Fri Oct 11 05:19:39 1996 From: tmb@best.com (Thomas Breuel) Date: Thu, 10 Oct 1996 21:19:39 -0700 Subject: [PYTHON DB-SIG] database API Message-ID: <199610110419.VAA02035@shellx.best.com> Hi, I found the Python Database API (PyDB) spec, but I'm a little confused: it seems to lack some abstractions that are present in JDBC and ODBC. PyDB's concept of a "cursor" seems to encompass (somehow) the concepts of "statement", "prepared statement", and "result set". But I can't tell from the API spec how a statement is prepared in the first place. And if I prepare it, I can't tell how I can use it multiple times, or how I can generate multiple result sets and then step through them simultaneously. Another reason why this kind of interface seems odd to me is because I view a "prepared statement" kind of like a collection class and a "result set" like an iterator over that collection class. Those are distinct concepts. While ODBC is perhaps unnecessarily complex, it seems to me that PyDB has been simplified a bit too much. Or maybe I just don't understand it. Can anyone explain? Also, why not base the PyDB interface directly either on the JDBC or the Perl DBI specs? It seems like there is a lot of design reuse possible. Thanks, Thomas. ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From tmb@best.com Sat Oct 12 01:33:10 1996 From: tmb@best.com (Thomas Breuel) Date: Fri, 11 Oct 1996 17:33:10 -0700 Subject: [PYTHON DB-SIG] SQL interface Message-ID: <199610120033.RAA09461@shellx.best.com> The database interface encompasses many databases, not just SQL. Thanks for the response. Unfortunately, it seems to me that Python's database interface is significantly more limited than ODBC, JDBC, or Perl DBI (see my previous message) and/or not specified in enough detail to actually write code that would be portable from one database to another. It seems to me that most database interfaces, whether they use SQL as their query language or not, should make a distinction between a prepared statement and an iterator over the set resulting from actually binding query parameters and executing the query. Of course, also, it isn't clear to me whether the generality of supporting non-SQL databases is really worth the limitations that that will impose on the interfaces; to put it differently, a special interface for Python to SQL databases analogous to ODBC or DBI would seem like a good idea to me. Is there still any kind of active discussion of those issues going on or are things frozen? Source code for ODBC is publically available in the PythonWin distribution. Somebody (I don't have the reference) ported the Win32 ODBC code to Unix ODBC code (mainly some simple tweaking of includes and removing some spurious C++ usage). You could create a DB2 implementation based on one of those, if DB2 is quite close to ODBC (or simply contact DB2 via the ODBC implementation and an ODBC driver for DB2). Thanks, that's nice to know. DB2's CLI interface is a superset of ODBC, so that should make things really easy. Thomas. ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From gstein@microsoft.com Fri Oct 11 20:10:42 1996 From: gstein@microsoft.com (Greg Stein) Date: Fri, 11 Oct 1996 12:10:42 -0700 Subject: [PYTHON DB-SIG] SQL interface Message-ID: The database interface encompasses many databases, not just SQL. There isn't a DB2 implementation that I know of. Source code for ODBC is publically available in the PythonWin distribution. Somebody (I don't have the reference) ported the Win32 ODBC code to Unix ODBC code (mainly some simple tweaking of includes and removing some spurious C++ usage). You could create a DB2 implementation based on one of those, if DB2 is quite close to ODBC (or simply contact DB2 via the ODBC implementation and an ODBC driver for DB2). -g >---------- >From: Thomas Breuel[SMTP:tmb@best.com] >Sent: Thursday, October 10, 1996 7:26 AM >To: db-sig@python.org >Subject: [PYTHON DB-SIG] SQL interface > >Hi, > >I was wondering what the status of the SQL database interface module >for Python is. I checked the FTP site (ftp.python.org) but couldn't >find anything. I need something fairly soon for interfacing with >DB2 (the API is basically ODBC), and I'd rather not invent my own >interface. > >Thanks, >Thomas. > >================= >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 tmb@best.com Sat Oct 12 05:03:35 1996 From: tmb@best.com (Thomas Breuel) Date: Fri, 11 Oct 1996 21:03:35 -0700 Subject: [PYTHON DB-SIG] database API Message-ID: <199610120403.VAA17566@shellx.best.com> |We (urm, the defunct eShop :-) implemented PyDB for ODBC quite snappily. |Works great. The interface also worked quite fine for Oracle and |Informix. Further, the interface had more than enough functionality for |actually building a serious server application. I'm not disputing that the current PyDB interface can be made to work, even efficiently. I still think that an interface that is closer to existing practice would be preferable and help Python to achieve greater acceptance as a database scripting language. |my_statement = "select * from some_table where col1 = :1 and col2 = :2" |cursor = connection.cursor() |cursor.execute(my_statement, params1) |rows1 = cursor.fetchall() |cursor.execute(my_statement, params2) |rows2 = cursor.fetchall() | |Specifically, if you pass in the *same* string objet for the statement, |then the implementations should reuse the statement that it prepared on |the prior execute(). | |The above example fetched all the rows at once; you can then step |through them as needed (most cases, you simply fetch them all). If your |results are too large to pull into memory and/or you need to be able to |terminate, you can do: | |cursor1 = connection.cursor() |cursor1.execute(statement1) |cursor2 = connection.cursor() |cursor2.execute(statement2) |while 1: | row1 = cursor1.fetchone() | row2 = cursor2.fetchone() This approach differs from established OO patterns (collection/iterator) as well as from the commonly used interfaces in other languages (JDBC, ODBC), which use separate data types to represent a prepared statement and an iterator over the result. In fact, a "prepared statement" can be holding a large amount of state, so this is not an academic difference. An alternative interface would be: prepared_statement = connection.prepare("... sql ...") result_set1 = prepared_statement.query(query_parameters1) result_set2 = prepared_statement.query(query_parameters2) for a in result_set1: for b in result_set2: do_something(a,b) Of course, in your example, cursor1 and cursor2 could somehow share state transparently behind the scenes. But that would discourage implementors from doing the right thing, and it would leave users confused about whether a particular implementation actually is doing the right thing. |The cursor object is a prepared statement. A result set is a list of |tuples. If it is a "prepared statement", why is it called a "cursor"? The term "cursor" has a specific meaning in databases, distinct from "prepared statement". |I believe that the interface can be even simpler (and still retain its |functionality). Jim Fulton has mentioned on several occasions over the |past 5 months ways to make the API simpler to work with, but has never |written anything down. If you want the simplest possible API, you can go a lot further. All you really need is a single function: dbquery(database_name, query_template,query_parameters, result_row,result_column) All the database and query state could be hidden by the implementation that way. That wouldn't be significantly less efficient than the PyDB interface or ODBC or JDBC. But it would make it even less obvious what state the database is and isn't keeping around behind the user's back and would differ even more from existing interfaces. "Simpler" isn't always "better". If you say that you are thinking about making this even simpler, that suggests to me that the database interface isn't set in stone yet. I hope very much that the PyDB interface could be modeled more on ODBC and JDBC, since that's what most users of databases are familiar with. The extra types and abstractions in those interfaces do serve a purpose. Furthermore, there would be a lot more prior art and experience for users to draw on. I think that JDBC in particular would be an excellent blueprint for a Python database interface. It seems to have about the right set of abstractions for convenient and efficient database access, and it is reasonably close to long-established practice (ODBC) while at the same time being quite convenient. Thomas. ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From gstein@microsoft.com Fri Oct 11 20:12:04 1996 From: gstein@microsoft.com (Greg Stein) Date: Fri, 11 Oct 1996 12:12:04 -0700 Subject: [PYTHON DB-SIG] Sybase Module with ctlib for linux? Message-ID: I'm replying just so you don't hear a void... seems like nobody here has much experience with the Sybase modules (which were developed outside of the db-sig by various people over the years). I'd recommend reposting your question to the main Python newsgroup. -g >---------- >From: Georg Mischler[SMTP:gm@hl-technik.de] >Sent: Sunday, October 06, 1996 1:30 PM >To: db-sig@python.org >Subject: [PYTHON DB-SIG] Sybase Module with ctlib for linux? > > >Hello out there ... > >I just managed to compile the included demos together with >Greg Thain's ELF converted open client libraries for sybase on my >Linux box. >(didn't check if they really work though yet ;) > >Next thing was trying to compile one of the several python >sybase modules (The most recent one and most complete looking >of them by Tim Docker with modifications by Thomas Palmer) >- with little success. >Although I link with every library file around (lacking other >instructions with the source), I still get tons of undefined >symbols in the end. > >What happens? >Are those modules not meant to use the open client libraries at all? >Does anything like this work on linux? > >Hard to imagine that there isn't any installation out there >where someone accesses a sybase database engine from a >python script on linux. Slowly beginning to feel really dumb... > > >Any further information highly appreciated! > >-Georg > > >Georg Mischler -- daylight&simulations -- mailto: >gm@hl-technik.de >HL-Technik AG -- consulting engineers -- >http://www.hl-technik.de > >================= >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 gstein@microsoft.com Fri Oct 11 20:07:17 1996 From: gstein@microsoft.com (Greg Stein) Date: Fri, 11 Oct 1996 12:07:17 -0700 Subject: [PYTHON DB-SIG] database API Message-ID: >---------- >From: Thomas Breuel[SMTP:tmb@best.com] >Sent: Thursday, October 10, 1996 9:19 PM >To: db-sig@python.org >Subject: [PYTHON DB-SIG] database API > >Hi, > >I found the Python Database API (PyDB) spec, but I'm a little >confused: it seems to lack some abstractions that are present in JDBC >and ODBC. We (urm, the defunct eShop :-) implemented PyDB for ODBC quite snappily. Works great. The interface also worked quite fine for Oracle and Informix. Further, the interface had more than enough functionality for actually building a serious server application. >PyDB's concept of a "cursor" seems to encompass (somehow) the concepts >of "statement", "prepared statement", and "result set". But I can't >tell from the API spec how a statement is prepared in the first >place. And if I prepare it, I can't tell how I can use it multiple >times, or how I can generate multiple result sets and then >step through them simultaneously. my_statement = "select * from some_table where col1 = :1 and col2 = :2" cursor = connection.cursor() cursor.execute(my_statement, params1) rows1 = cursor.fetchall() cursor.execute(my_statement, params2) rows2 = cursor.fetchall() Specifically, if you pass in the *same* string objet for the statement, then the implementations should reuse the statement that it prepared on the prior execute(). The above example fetched all the rows at once; you can then step through them as needed (most cases, you simply fetch them all). If your results are too large to pull into memory and/or you need to be able to terminate, you can do: cursor1 = connection.cursor() cursor1.execute(statement1) cursor2 = connection.cursor() cursor2.execute(statement2) while 1: row1 = cursor1.fetchone() row2 = cursor2.fetchone() >Another reason why this kind of interface seems odd to me is >because I view a "prepared statement" kind of like a collection >class and a "result set" like an iterator over that collection >class. Those are distinct concepts. The cursor object is a prepared statement. A result set is a list of tuples. >While ODBC is perhaps unnecessarily complex, it seems to me that >PyDB has been simplified a bit too much. Or maybe I just don't >understand it. Can anyone explain? Also, why not base the PyDB >interface directly either on the JDBC or the Perl DBI specs? It >seems like there is a lot of design reuse possible. PyDB exposes just about everything you might need for database operations. Even high-performance reuse of prepared statements, input and output binding, and notation of bind sizes. I would ask: what does it not allow you to do? I believe that the interface can be even simpler (and still retain its functionality). Jim Fulton has mentioned on several occasions over the past 5 months ways to make the API simpler to work with, but has never written anything down. -g > ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From aaron_watters@msn.com Sun Oct 13 03:42:13 1996 From: aaron_watters@msn.com (aaron watters) Date: Sun, 13 Oct 96 02:42:13 UT Subject: [PYTHON DB-SIG] database API Message-ID: Thomas: Is there some reason you couldn't wrap the present interface in your-favorite-framework in python code (without too much overhead) and get what you want? (Putting issues of possible faulty implementations aside; if the spec is ambiguous to permit faulty implementations it should be tightened...) There, that question was abstract enough that I could ask it without really understanding the issues! Ha! In particular, forgive me for being a moron again, but where was that python/db spec? last time I looked at the python.org site it didn't show. (reply privately with url somebody or everybody, please - I wanna try out the ODBC module, and if it works maybe put it to real use with MSAccess on Tuesday...) -- Aaron Watters ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From tmb@best.com Sun Oct 13 04:54:19 1996 From: tmb@best.com (Thomas Breuel) Date: Sat, 12 Oct 1996 20:54:19 -0700 Subject: [PYTHON DB-SIG] database API Message-ID: <199610130354.UAA06366@shellx.best.com> Thomas: Is there some reason you couldn't wrap the present interface in your-favorite-framework in python code (without too much overhead) and get what you want? Well, it isn't really a question of my personal taste. Sure, I can get something to work with a PyDB implementation, somehow. Of course, since I need to implement a DB2 interface myself anyway... But the interface is different from similar interfaces in other languages: it has eliminated one or two important concepts and instead hints to the implementor at providing additional functionality behind the scenes. That has several consequences: -- experienced users familiar with analogous APIs in other languages will be confused about how functionality they know from other APIs is provided by the PyDB API -- the API will give less guidance to novice users as to what the underlying abstractions actually are, since some of them are hidden -- implementors will receive less guidance about what is expected from a high quality implementation, since some of the abstractions required aren't made explicit -- PyDB will probably be looked at as being somewhat inferior to other database APIs I'm frankly not quite sure yet what to do. I will probably want to provide a scripting language and CGI interface to a multimedia database product based on DB2. Python, Perl, Java, and Tcl are possible choices. I think the current PyDB spec makes Python a less attractive choice than a PyDB spec that would be more closely modeled on ODBC or JDBC. Most of the potential users are not going to be familiar with Python or PyDB, but they probably do know ODBC or JDBC. In particular, forgive me for being a moron again, but where was that python/db spec? last time I looked at the python.org site it didn't show. (reply privately with url somebody or everybody, please - I wanna try out the ODBC module, and if it works maybe put it to real use with MSAccess on Tuesday...) I don't have the URL handy; I'll try and send it out next time I log into my work machine. I have also sketched out a PyDB interface analogous to JDBC, which I may include for people to look at. While the JDBC spec is relatively long, most of that is because of the profusion of statically typed methods required to satisfy Java's static type checker; those drop out in a "PyDBC" interface, and something like that turns out not to be more complex than the current PyDB interface. Cheers, Thomas. ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From gstein@microsoft.com Sun Oct 13 05:33:03 1996 From: gstein@microsoft.com (Greg Stein) Date: Sat, 12 Oct 1996 21:33:03 -0700 Subject: [PYTHON DB-SIG] database API Message-ID: >---------- >From: Thomas Breuel[SMTP:tmb@best.com] >Sent: Friday, October 11, 1996 9:03 PM >To: Greg Stein; 'Thomas Breuel'; 'db-sig@python.org' >Subject: RE: [PYTHON DB-SIG] database API > >I'm not disputing that the current PyDB interface can be made >to work, even efficiently. I still think that an interface that >is closer to existing practice would be preferable and help >Python to achieve greater acceptance as a database scripting >language. The intention was to make the interface more Python-ish, not a simple port of existing APIs. >This approach differs from established OO patterns >(collection/iterator) as well as from the commonly used interfaces in >other languages (JDBC, ODBC), which use separate data types to >represent a prepared statement and an iterator over the result. "Established OO patterns" ?? Excuse me, but I've been doing this stuff for a long time. I've never noticed any particular pattern. Python does not use iterators; therefore, introducing them is not a very Python-ish concept. Instead, Python iterates over a list using the "for" statement. For example: for row in cursor.fetchall(): do whatever Jim Fulton has suggested that the cursor object should respond to __getitem__ so it can be directly used in a for loop. That would be cool, but he's never actually written them down, so the spec and the various implementations remain the same. >In fact, a "prepared statement" can be holding a large amount >of state, so this is not an academic difference. An alternative >interface would be: > > prepared_statement = connection.prepare("... sql ...") > result_set1 = prepared_statement.query(query_parameters1) > result_set2 = prepared_statement.query(query_parameters2) > for a in result_set1: > for b in result_set2: > do_something(a,b) Here was the form I suggested: |my_statement = "select * from some_table where col1 = :1 and col2 = :2" |cursor = connection.cursor() |cursor.execute(my_statement, params1) |rows1 = cursor.fetchall() |cursor.execute(my_statement, params2) |rows2 = cursor.fetchall() The two forms are similar, if you replace rows1/rows2 for result_set1/result_set2. You've applied a bit more glue on top than the current API. The standard Python approach is to apply only a little glue when writing in C, deferring higher-level semantics to Python code. Creating a concept like you mention would be quite simple in Python. >Of course, in your example, cursor1 and cursor2 could somehow >share state transparently behind the scenes. But that would discourage >implementors from doing the right thing, and it would leave users >confused about whether a particular implementation actually is >doing the right thing. You're confusing demos. The cursor1/cursor2 demo was showing two separate cursor in use while fetching rows (rather than fetching both sets all at once). Since they are two cursors, they probably are not sharing much beyond the database connection itself. >|The cursor object is a prepared statement. A result set is a list of >|tuples. > >If it is a "prepared statement", why is it called a "cursor"? The >term "cursor" has a specific meaning in databases, distinct from >"prepared statement". It is called a cursor because it corresponds to a database cursor. I'm trying to show you that you could look at it as a prepared statement. If you run the execute() method on it, then the cursor object now contains a prepared statement. >If you want the simplest possible API, you can go a lot further. All >you really need is a single function: > > dbquery(database_name, > query_template,query_parameters, > result_row,result_column) Yes, you sure could. Write it in Python, calling on the PyDB interface to the underlying database. That is normally how Python code is written. C modules supply a minimum, Python modules supply whatever you want. >All the database and query state could be hidden by the implementation >that way. That wouldn't be significantly less efficient than the >PyDB interface or ODBC or JDBC. But it would make it even less obvious >what state the database is and isn't keeping around behind the >user's back and would differ even more from existing interfaces. >"Simpler" isn't always "better". Nobody said simpler was better, but that simpler can make certain operations simpler. The API was designed with "Simple things should be simple, complex things should be doable." Somebody could use it with something like: con = odbc.odbc(connect_string) con.execute(query_string, query_params) results = con.fetchall() Sure, this has no consideration for special input/output binding, no result buffer sizes, no handling of database cursors, etc, but it gets the job done very simply. The spec does allow for all the rest for more complex tasks. >If you say that you are thinking about making this even simpler, that >suggests to me that the database interface isn't set in stone yet. >I hope very much that the PyDB interface could be modeled more on ODBC >and JDBC, since that's what most users of databases are familiar with. >The extra types and abstractions in those interfaces do serve a purpose. >Furthermore, there would be a lot more prior art and experience for >users to draw on. I'm not thinking about any changes whatsoever. The current API has suited me since last January. The only person that has ever suggested changes has been Jim. Beyond that, I consider it quite set in stone since its been used successfully for several databases already. Using an existing API such as ODBC or JDBC makes sense because people will be used to it. Problem is that most of those things aren't designed with Python in mind. In another note, you mentioned how a bulk of JDBC was designed to compensate for static typing. The current API has been built with Python in mind, and so it makes much more sense for Python programmers. >I think that JDBC in particular would be an excellent blueprint for >a Python database interface. It seems to have about the right set of >abstractions for convenient and efficient database access, and it is >reasonably close to long-established practice (ODBC) while at the >same time being quite convenient. Quite possibly true. I would recommend that you write a spec on how you believe it should work and run it by people for comment. Even without comment, you'd be free to build your DB2 interface using that spec. Share your implemented module when you're done. Code talks. -g ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From gstein@microsoft.com Sun Oct 13 05:37:28 1996 From: gstein@microsoft.com (Greg Stein) Date: Sat, 12 Oct 1996 21:37:28 -0700 Subject: [PYTHON DB-SIG] SQL interface Message-ID: >---------- >From: Thomas Breuel[SMTP:tmb@best.com] >Sent: Friday, October 11, 1996 5:33 PM >To: Greg Stein >Cc: db-sig@python.org >Subject: RE: [PYTHON DB-SIG] SQL interface > > The database interface encompasses many databases, not just SQL. > >Thanks for the response. Unfortunately, it seems to me that Python's >database interface is significantly more limited than ODBC, JDBC, or >Perl DBI (see my previous message) and/or not specified in enough >detail to actually write code that would be portable from one database >to another. It seems to me that most database interfaces, whether they The standard Python approach is to writing a C module to expose functionality, not add value. The API was designed to expose as much of a database's functionality as possible, not to make things portable from one database to another. It was decided a long time ago to not attempt to do that. What would happen is that you'd end up with a lowest common denominator or a really complex specification. Instead, the approach that was taken was to write something that enabled most of a database's capabilities within Python. Additional layers, in Python, could then be used to create a truly portable API. >use SQL as their query language or not, should make a distinction >between a prepared statement and an iterator over the set resulting >from actually binding query parameters and executing the query. > >Of course, also, it isn't clear to me whether the generality of >supporting non-SQL databases is really worth the limitations that >that will impose on the interfaces; to put it differently, >a special interface for Python to SQL databases analogous to ODBC >or DBI would seem like a good idea to me. So far, nobody has tried to use the API for non-SQL databases. It doesn't map well to dbm style. I'm not sure what other types are out there that people would be interested in using from Python. >Is there still any kind of active discussion of those issues going on >or are things frozen? The discussion you've started is the first thing since last April or so. :-) -g > ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From gstein@microsoft.com Sun Oct 13 05:46:50 1996 From: gstein@microsoft.com (Greg Stein) Date: Sat, 12 Oct 1996 21:46:50 -0700 Subject: [PYTHON DB-SIG] database API Message-ID: >---------- >From: Thomas Breuel[SMTP:tmb@best.com] >Sent: Saturday, October 12, 1996 8:54 PM >To: Greg Stein; Thomas Breuel; Thomas Breuel; db-sig@python.org; aaron >watters >Subject: RE: [PYTHON DB-SIG] database API > >But the interface is different from similar interfaces in other >languages: it has eliminated one or two important concepts and instead >hints to the implementor at providing additional functionality behind >the scenes. That has several consequences: Please suggest improvements and corrections to the spec if you find shortcomings. That will help everybody -- users and implementors alike. > -- experienced users familiar with analogous APIs in other > languages will be confused about how functionality they > know from other APIs is provided by the PyDB API This is true and an unfortunate consequence. It was decided to create an API more Pythonish than representative of existing (C-based) APIs. > -- the API will give less guidance to novice users as to > what the underlying abstractions actually are, since > some of them are hidden Users don't need to know the underlying abstractions. They just need access to the data in their database. They need to understand the abstractions exposed by PyDB, not the database. > -- implementors will receive less guidance about what is > expected from a high quality implementation, since some > of the abstractions required aren't made explicit Please point these out, then, so we can get the current spec updated with as much information as possible. The ODBC implementation, at least, can help steer people towards the right direction when implementing. Unfortunately, it is not the highest quality implementation (there is no implicit cursor on the connection and I'm not sure that it reuses cursors and data binding areas fully). When somebody finds they need that, then they can implement it and redistribute the updates. If nobody ever does, then that means the current implementation is satisfactory for users (i.e. why build more than people actually need?) > -- PyDB will probably be looked at as being somewhat inferior > to other database APIs I've never seen it that way and I've seen a number of APIs. I find the interface quite refreshing to use. There is no way you could get me to write database code in anything besides Python, and the reason is solely based on the ease of use of the PyDB API. >I think the current PyDB spec makes Python a less attractive choice >than a PyDB spec that would be more closely modeled on ODBC or JDBC. >Most of the potential users are not going to be familiar with Python or >PyDB, but they probably do know ODBC or JDBC. A number of people have used the ODBC version to quite some success. The underlying question here is whether you are trying to attract people to using Python to perform database operations, or trying to fulfill Python users' needs for database operations. I believe that we fulfilled the latter. > In particular, forgive me for being a moron again, but where was > that python/db spec? last time I looked at the python.org site it > didn't show. (reply privately with url somebody or everybody, > please - I wanna try out the ODBC module, and if it works maybe put > it to real use with MSAccess on Tuesday...) http://www.python.org/sigs/db-sig/DatabaseAPI.html. I tried to fix up the pages the other weekend, but ran into some problems. Ken fixed it and I should be able to fix up the pages. >I don't have the URL handy; I'll try and send it out next time I log >into my work machine. I have also sketched out a PyDB interface >analogous to JDBC, which I may include for people to look at. >While the JDBC spec is relatively long, most of that is because >of the profusion of statically typed methods required to satisfy >Java's static type checker; those drop out in a "PyDBC" interface, >and something like that turns out not to be more complex than the >current PyDB interface. Please post your spec to this forum. It would be good to actually see an alternative. Also, wouldn't it be PDBC ? :-) -g ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From tmb@best.com Sun Oct 13 07:36:58 1996 From: tmb@best.com (Thomas Breuel) Date: Sat, 12 Oct 1996 23:36:58 -0700 Subject: [PYTHON DB-SIG] database API Message-ID: <199610130636.XAA17723@shellx.best.com> "Established OO patterns" ?? Excuse me, but I've been doing this stuff for a long time. I've never noticed any particular pattern. Python does not use iterators; therefore, introducing them is not a very Python-ish concept. Instead, Python iterates over a list using the "for" statement. For example: for row in cursor.fetchall(): do whatever That's fine, but not quite what I'm trying to get at. The main distinction I think is missing from PyDB is that between a Connection, a PreparedStatement, and a ResultSet/Cursor. Recognizing that you are reexecuting a query with what happens to be the same string just does not seem right to me, and, in any case, differs substantially from the approach taken by database APIs in other languages. Quite possibly true. I would recommend that you write a spec on how you believe it should work and run it by people for comment. Even without comment, you'd be free to build your DB2 interface using that spec. Share your implemented module when you're done. Code talks. Yes, I'm aware of that, and I appreciate the effort that has gone into PyDB. I also appreciate that you and others have done some successful work with PyDB and found it to be convenient to work with. But please be aware that there are other concerns, related both to how familar an API will be to other users, and whether convenience hasn't been bought at the expense of letting an important abstraction fall under the table. I'm approaching this first of all as a "consumer": under what conditions can I choose Python/PyDB over an equivalent Perl/DBI or Tcl solution. Python already will be less familiar to our potential users, so any deviation of PyDB from more familar APIs like ODBC or JDBC is an additional negative. My technical preference for Python as a language is only one of a number of factors. I suspect that my concerns are fairly typical for people considering doing database work in Python. In any case, I'll give it more thought and maybe send out a spec, and possibly a wrapper around existing code, that might form a more concrete basis for a discussion. But that makes only sense if there is some willingness to talk about such changes to PyDB. I have no interest in setting up a competing standard; if I should feel (I haven't made up my mind yet) that the current PyDB API is so different from what our user community expects that that was necessary and that it couldn't be changed, I'd simply go with another solution rather than fight over this. Thomas. ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From gstein@microsoft.com Sun Oct 13 08:14:31 1996 From: gstein@microsoft.com (Greg Stein) Date: Sun, 13 Oct 1996 00:14:31 -0700 Subject: [PYTHON DB-SIG] database API Message-ID: >---------- >From: Thomas Breuel[SMTP:tmb@best.com] >Sent: Saturday, October 12, 1996 11:36 PM >To: Greg Stein; 'Thomas Breuel' >Cc: 'db-sig@python.org' >Subject: RE: [PYTHON DB-SIG] database API > >That's fine, but not quite what I'm trying to get at. The main >distinction I think is missing from PyDB is that between a Connection, >a PreparedStatement, and a ResultSet/Cursor. Recognizing that you >are reexecuting a query with what happens to be the same string just >does not seem right to me, and, in any case, differs substantially from >the approach taken by database APIs in other languages. I fully agree that it is not obvious. :-( While a definite shortcoming, it hasn't ever bothered me enough... :-) >I'm approaching this first of all as a "consumer": under what >conditions can I choose Python/PyDB over an equivalent Perl/DBI or Tcl >solution. Python already will be less familiar to our potential users, >so any deviation of PyDB from more familar APIs like ODBC or JDBC is an >additional negative. My technical preference for Python as a language >is only one of a number of factors. I suspect that my concerns are >fairly typical for people considering doing database work in Python. Could be. Unfortunately, I haven't spent the time to get the darn spec more widely published (outside of this sig) and modules implementing it were not freely available (outside of eShop :-) until only very recently. In other words... it is only until very recently that people have had a chance to work with the current spec. If you're still choosing your language... well... hrm. :-) Like I said, I think the API speak more to people who may have chosen Python already. Nevertheless, with your input, changes could help to broaden Python's database appeal. However, I'll also point out that, at least as far as this sig goes, people have had very little comments for change. Whether from it being correct, or people just being quiet, I have no idea :-) >In any case, I'll give it more thought and maybe send out a spec, and >possibly a wrapper around existing code, that might form a more >concrete basis for a discussion. But that makes only sense if there is >some willingness to talk about such changes to PyDB. I have no >interest in setting up a competing standard; if I should feel (I >haven't made up my mind yet) that the current PyDB API is so different >from what our user community expects that that was necessary and that >it couldn't be changed, I'd simply go with another solution rather than >fight over this. As I mentioned, people haven't had much exposure to the current spec, so actual input would be welcome (as far as I'm concerned). I'll throw in one caveat to this whole thing, though: I'm not involved with the coding of database modules anymore for Python. My needs/interests have diverged since I first started applying thought and time to Python's database interfaces. Changes to existing modules and developing new ones would need to be done by others. I'll gladly contribute talk and viewpoints and whatnot, but coding is a different story. Heh. And a note my philosophy book: he who codes it, wins the spec argument over he who does not. :-) Cheers, -g ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From fredrik_lundh@ivab.se Mon Oct 14 10:21:56 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Mon, 14 Oct 1996 11:21:56 +0200 Subject: [PYTHON DB-SIG] database API In-Reply-To: <199610130636.XAA17723@shellx.best.com> (message from Thomas Breuel on Sat, 12 Oct 1996 23:36:58 -0700) Message-ID: <9610140921.AA19639@arnold.image.ivab.se> > That's fine, but not quite what I'm trying to get at. The main > distinction I think is missing from PyDB is that between a > Connection, a PreparedStatement, and a ResultSet/Cursor. Agreed (I think). > In any case, I'll give it more thought and maybe send out a spec, > and possibly a wrapper around existing code, that might form a more > concrete basis for a discussion. Go ahead! > But that makes only sense if there is some willingness to talk about > such changes to PyDB. Sure is! Cheers /F ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From fredrik_lundh@ivab.se Mon Oct 14 10:32:56 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Mon, 14 Oct 1996 11:32:56 +0200 Subject: [PYTHON DB-SIG] database API Message-ID: <9610140932.AA19580@arnold.image.ivab.se> Greg writes: > "Established OO patterns" ?? Excuse me, but I've been doing this > stuff for a long time. I've never noticed any particular pattern. > Python does not use iterators; therefore, introducing them is not a > very Python-ish concept. Instead, Python iterates over a list using > the "for" statement. /.../ > Jim Fulton has suggested that the cursor object should respond to > __getitem__ so it can be directly used in a for loop. Which is exactly what at least I would call an iterator :-) >From Design Patterns [GOF 1994]: "Iterator -- provide a way to access the elements of an aggregate object sequencially without exposing its underlying representation." Cheers /F ================= 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 Oct 16 15:00:27 1996 From: jim.fulton@digicool.com (Jim Fulton) Date: Wed, 16 Oct 1996 10:00:27 -0400 Subject: [PYTHON DB-SIG] Jim's DBAPI proposelet Message-ID: <3264EA7B.3CC6@digicool.com> As has been mentioned several times, I have a number of ideas for improving the Python Database API. I apologize for not providing input earlier due to conflicting priorities. These conflicting priorities persist, so my tardy input is likely to continue. My interest in the database API is based on experience with developing 3 separate Python database extesnions. These were for three *tabular* databases: Ingres, Arc/Info (a GIS system), and Rand RDB (similar to and inspired by the /rdb product). Only one of these databases is SQL based. A guiding principle is that these interfaces should be as simple and intuitive as possible, using existing protocols/models, and where possible, promoting portability. Here are some high-level notions: - Result tables should be *sequences* is database records. These sequences might only allow sequential access, that is for loop access, so as to avoid having to store all data in memory. - Database records should be: o Sequences of values o Mappings from column name to value o Records, supporting attribute access of column values - Result table meta-data objects should provide access to column definitions and other meta-data and should be shared by both result tables and by database records. - It should be possible to subclass result tables in some fashion to add methods and to treat database records as instances. (I have not implemented this yet, but have been thinking quite seriously about it.) - Database objects model and encapsulate database connections. - Database objects provide methods to create prepared statements, result tables, and to execute sql statements immediately. - Prepared statements should look like functions. - Here are some examples that show, informally, what I think we should shoot for. from somedb import Database db=Database("...some connection string...") for r in db.execute("select * from spam"): ...do stuff with r... # Notice the use of standard python format strings. # This would have to be extended to accomodate # additional types, such as dates and blobs. ins=db.prepare('insert into spam values(%s,%d,%f)') ins('hello',23,123.456) # Note the use of None to input null values. ins('bye',None,None) - The database execute method and prepared statements should either return a result table, an integer number of rows updated or inserted, or None. There are a number of issues that need to be addressed: - A standard exception model. For example, there need to be ways of specific errors, such as: - Invalid statements, - Lost database connections, - Invalid arguments to prepared statements. - ... - A standard mete-data mechanism. We need to define what meta-data objects look like. Here's what I've done: o Meta-data objects are accessed via __dict__ attributes of result tables or rows. o Meta-data objects are sequences of column definitions. o Meta-data objects are mappings from column names to column definitions. o Meta-data objects have keys, items, and values methods that return data ordered on column number. o Column definitions are mapping objects that map column attribute names to column attribute values. There should be standard column attributes, such as: name, type, and remark, as well as database specific attributes. There should be some standard types, but what are they and how should they be represented? I'm sure that there are other details I'm forgetting, but this at least provides a first cut at writing these down. If people seem to think that the approach outlined is sound, then I'd be happy to come up with a more formal proposal. I've got to run. Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.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 jim.fulton@digicool.com Fri Oct 18 23:28:56 1996 From: jim.fulton@digicool.com (Jim Fulton) Date: Fri, 18 Oct 1996 18:28:56 -0400 Subject: [Fwd: [PYTHON DB-SIG] Jim's DBAPI proposelet] Message-ID: <326804A8.48E0@digicool.com> This is a multi-part message in MIME format. --------------1755445652AE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi. I sent the attached proposelet a few days ago. Given recent discussions, I really thought It would generate some feedback, but I haven't heard a peep. This makes me wonder whether people actually got the message. If a few of you would just acknowledge this note with private mail, I'll know that the communication lines are still working. :-) Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.python.org/ ## --------------1755445652AE Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from gator.digicool.com ([204.183.226.49]) by willy.digicool.com (post.office MTA v2.0 0813 ID# 0-12178) with SMTP id AAA40 for ; Wed, 16 Oct 1996 10:35:39 -0400 Received: from python.org (larch.python.org [132.151.1.89]) by gator.digicool.com (8.6.9/8.6.5) with ESMTP id KAA17027; Wed, 16 Oct 1996 10:29:08 -0400 Received: (from majordom@localhost) by python.org (8.7.5/8.7.3)id KAA07802 for db-sig-people; Wed, 16 Oct 1996 10:04:20 -0400 (EDT) Received: from willy.digicool.com (willy.digicool.com [204.183.226.70]) by python.org (8.7.5/8.7.3) with ESMTPid KAA07797 for ; Wed, 16 Oct 1996 10:04:17 -0400 (EDT) Received: from glebe ([204.183.226.81]) by willy.digicool.com (post.office MTA v2.0 0813 ID# 0-12178) with SMTP id AAA341 for ; Wed, 16 Oct 1996 10:00:46 -0400 Message-ID: <3264EA7B.3CC6@digicool.com> Date: Wed, 16 Oct 1996 10:00:27 -0400 From: Jim Fulton Organization: Digital Creations, L.C. X-Mailer: Mozilla 3.0Gold (WinNT; I) MIME-Version: 1.0 To: db-sig@python.org Subject: [PYTHON DB-SIG] Jim's DBAPI proposelet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-db-sig@python.org Precedence: bulk As has been mentioned several times, I have a number of ideas for improving the Python Database API. I apologize for not providing input earlier due to conflicting priorities. These conflicting priorities persist, so my tardy input is likely to continue. My interest in the database API is based on experience with developing 3 separate Python database extesnions. These were for three *tabular* databases: Ingres, Arc/Info (a GIS system), and Rand RDB (similar to and inspired by the /rdb product). Only one of these databases is SQL based. A guiding principle is that these interfaces should be as simple and intuitive as possible, using existing protocols/models, and where possible, promoting portability. Here are some high-level notions: - Result tables should be *sequences* is database records. These sequences might only allow sequential access, that is for loop access, so as to avoid having to store all data in memory. - Database records should be: o Sequences of values o Mappings from column name to value o Records, supporting attribute access of column values - Result table meta-data objects should provide access to column definitions and other meta-data and should be shared by both result tables and by database records. - It should be possible to subclass result tables in some fashion to add methods and to treat database records as instances. (I have not implemented this yet, but have been thinking quite seriously about it.) - Database objects model and encapsulate database connections. - Database objects provide methods to create prepared statements, result tables, and to execute sql statements immediately. - Prepared statements should look like functions. - Here are some examples that show, informally, what I think we should shoot for. from somedb import Database db=Database("...some connection string...") for r in db.execute("select * from spam"): ...do stuff with r... # Notice the use of standard python format strings. # This would have to be extended to accomodate # additional types, such as dates and blobs. ins=db.prepare('insert into spam values(%s,%d,%f)') ins('hello',23,123.456) # Note the use of None to input null values. ins('bye',None,None) - The database execute method and prepared statements should either return a result table, an integer number of rows updated or inserted, or None. There are a number of issues that need to be addressed: - A standard exception model. For example, there need to be ways of specific errors, such as: - Invalid statements, - Lost database connections, - Invalid arguments to prepared statements. - ... - A standard mete-data mechanism. We need to define what meta-data objects look like. Here's what I've done: o Meta-data objects are accessed via __dict__ attributes of result tables or rows. o Meta-data objects are sequences of column definitions. o Meta-data objects are mappings from column names to column definitions. o Meta-data objects have keys, items, and values methods that return data ordered on column number. o Column definitions are mapping objects that map column attribute names to column attribute values. There should be standard column attributes, such as: name, type, and remark, as well as database specific attributes. There should be some standard types, but what are they and how should they be represented? I'm sure that there are other details I'm forgetting, but this at least provides a first cut at writing these down. If people seem to think that the approach outlined is sound, then I'd be happy to come up with a more formal proposal. I've got to run. Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.python.org/ ## ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= --------------1755445652AE-- ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From mlorton@microsoft.com Sat Oct 19 01:31:21 1996 From: mlorton@microsoft.com (Michael Lorton) Date: Fri, 18 Oct 1996 17:31:21 -0700 Subject: [Fwd: [PYTHON DB-SIG] Jim's DBAPI proposelet] Message-ID: >Hi. I sent the attached proposelet a few days ago. Given recent >discussions, I really thought It would generate some feedback, but >I haven't heard a peep. This makes me wonder whether people actually >got the message. If a few of you would just acknowledge this >note with private mail, I'll know that the communication lines are >still working. :-) > I didn't see the first copy but maybe that was just me. Points: + I don't see how you intend to store prepare statement + I don't understand how you distinguish "result set" from cursor (I mean, I don't see both concepts separately embodied in code) + I think the datatypes (String, Number, Raw, and Date) are good and we should keep 'em. + I think the exception model (OpError, ProgError, IntegrityError, DataError) is good and we should keep it too. To defend the last to points: RDMSs' myriad fine distinctions among types (what is a tinyint vs. a byte vs. a boolean?) is almost useless (IMHO); I cannot see why exposing it to the user helps any. While the programmer needs access to very specific error messages, the program cannot be expected to understand the difference between (say) Database Disconnect and Database Shutdown. High-level catagory are much more helpful. M. ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From gstein@svpal.org Sat Oct 19 09:25:12 1996 From: gstein@svpal.org (Greg Stein) Date: Sat, 19 Oct 1996 01:25:12 -0700 Subject: [PYTHON DB-SIG] finally! Message-ID: <32689068.4B0CABA9@svpal.org> I updated the main db-sig page and tweaked the spec page a bit (just the stuff at the top, not the spec itself yet). -g -- Greg Stein (gstein@svpal.org) execfile("disclaimer.py") ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From ksavage@kamro.com Wed Oct 23 03:23:30 1996 From: ksavage@kamro.com (Karen Savage) Date: Tue, 22 Oct 1996 19:23:30 -0700 Subject: [PYTHON DB-SIG] Converting strings to numbers Message-ID: <199610230222.TAA02841@maya.kamro.com> This seems like it should be easy to do, but I can't figure it out. I have a string variable containing a numeric value. (i.e. '3'). I want to convert it to a numeric variable type. Any ideas? Also is there an equivalent of an IsNumber(string) call that tells you if a string value can be converted to a numeric? ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From hal-j@alpha.netusa.net Wed Oct 23 10:19:05 1996 From: hal-j@alpha.netusa.net (Hal J Schechner) Date: Wed, 23 Oct 1996 05:19:05 -0400 (EDT) Subject: [PYTHON DB-SIG] Converting strings to numbers In-Reply-To: <199610230222.TAA02841@maya.kamro.com> Message-ID: On Tue, 22 Oct 1996, Karen Savage wrote: > This seems like it should be easy to do, but I can't figure it out. I have > a string variable containing a numeric value. (i.e. '3'). I want to convert > it to a numeric variable type. Any ideas? Also is there an equivalent of > an IsNumber(string) call that tells you if a string value can be converted > to a numeric? > This can not only be done from string reps of a number to a numeric type, but also from string reps of anything (lists, tuples, dicts etc..) to thier actual type. ( nice for reading plaintext datafiles ). example: Python 1.3 (Oct 13 1996) [GCC 2.7.2] Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> foo = '3.14159' >>> foo '3.14159' >>> bar = eval(foo) >>> bar 3.14159 >>> bar + 1.0 4.14159 >>> >>> Foo = '[1,2,3,4,5,6,7]' >>> Foo '[1,2,3,4,5,6,7]' >>> Foo[0] '[' >>> Bar = eval(Foo) >>> Bar [1, 2, 3, 4, 5, 6, 7] >>> Bar[0] 1 >>> -Hal Schechner -=[Hal Schechner]-=-=-=-=System Administration=-=-=-=-=(hal-j@NetUSA.Net)=- I'm sorry, he can't come to the phone right now. His foot is caught in the ceiling fan. -=[Finger for public key]-=-=-=-=-=-=-=-=-=[http://www.NetUSA.Net/~hal-j]=- ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From fredrik_lundh@ivab.se Wed Oct 23 11:07:07 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Wed, 23 Oct 1996 12:07:07 +0200 Subject: [PYTHON DB-SIG] Converting strings to numbers In-Reply-To: (message from Hal J Schechner on Wed, 23 Oct 1996 05:19:05 -0400 (EDT)) Message-ID: <9610231007.AA01416@arnold.image.ivab.se> > This can not only be done from string reps of a number to a numeric > type, but also from string reps of anything (lists, tuples, dicts > etc..) to thier actual type. ( nice for reading plaintext datafiles > ). Note that eval is compact but dangerous; consider the following (on a Unix box): eval('os.remove("rm -rf ~/*")') Use string.atoi() and string.atof() when you need to be on the safe side. /F ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From hal-j@alpha.netusa.net Wed Oct 23 14:13:08 1996 From: hal-j@alpha.netusa.net (Hal J Schechner) Date: Wed, 23 Oct 1996 09:13:08 -0400 (EDT) Subject: [PYTHON DB-SIG] Converting strings to numbers In-Reply-To: <9610231007.AA01416@arnold.image.ivab.se> Message-ID: On Wed, 23 Oct 1996, Fredrik Lundh wrote: > > > This can not only be done from string reps of a number to a numeric > > type, but also from string reps of anything (lists, tuples, dicts > > etc..) to thier actual type. ( nice for reading plaintext datafiles > > ). > > Note that eval is compact but dangerous; consider the following (on a > Unix box): > > eval('os.remove("rm -rf ~/*")') > > Use string.atoi() and string.atof() when you need to be on the safe > side. > This is fine when working with floats or integers, but like I stated, there are times (like when trying to restore tuples, lists etc..) when you cant use one of the lib functions. Of course, you would want to make sure you are safe when you do it, and making a wrapper would be the 'right' way of doing it. I was only pointing out that it *is* possible to do it ;) -Hal Schechner -=[Hal Schechner]-=-=-=-=System Administration=-=-=-=-=(hal-j@NetUSA.Net)=- Are you SURE no one changed ANYTHING in your configuration?!?! -=[Finger for public key]-=-=-=-=-=-=-=-=-=[http://www.NetUSA.Net/~hal-j]=- ================= 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 Oct 23 14:55:03 1996 From: jim.fulton@digicool.com (Jim Fulton) Date: Wed, 23 Oct 1996 09:55:03 -0400 Subject: [PYTHON DB-SIG] Converting strings to numbers References: Message-ID: <326E23B7.4C90@digicool.com> Hal J Schechner wrote: > > On Wed, 23 Oct 1996, Fredrik Lundh wrote: > > > > > > This can not only be done from string reps of a number to a numeric > > > type, but also from string reps of anything (lists, tuples, dicts > > > etc..) to thier actual type. ( nice for reading plaintext datafiles > > > ). > > > > Note that eval is compact but dangerous; consider the following (on a > > Unix box): > > > > eval('os.remove("rm -rf ~/*")') > > > > Use string.atoi() and string.atof() when you need to be on the safe > > side. > > > > This is fine when working with floats or integers, but like I stated, there > are times (like when trying to restore tuples, lists etc..) when you cant > use one of the lib functions. Of course, you would want to make sure you > are safe when you do it, and making a wrapper would be the 'right' way of > doing it. I was only pointing out that it *is* possible to do it ;) It is worth noting that a safe way to use eval, if you know you don't need to execute any functions is: eval(s, {'__builtins__': {}}) This is a "restricted execution" form of eval. Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.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 johnm@magnet.com Wed Oct 23 18:44:36 1996 From: johnm@magnet.com (John Mitchell) Date: Wed, 23 Oct 1996 13:44:36 -0400 (EDT) Subject: [PYTHON DB-SIG] PATCH for Msql 1.0.16 and Python 1.4b3 Message-ID: Selecting from a table with NULLs results in a coredump from Python, command-line msql works fine. What was happening was that the (antique) msqlmodule was trying to do newstiringobject(NULL) -- boom! This will fix it, around line 207: change: str=newstringobject(thisrow[i]); to: if (!thisrow[i]) { INCREF(None); str = None; } else { str=newstringobject(thisrow[i]); } Is anyone maintaining the msqlmodule.c? - j John Mitchell my body .. abused. my mind .. unhinged. Magnet Interactive my reality .. maintained. I am happy. johnm@magnet.com -- Too Much Coffee Man ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From gstein@microsoft.com Wed Oct 23 20:45:23 1996 From: gstein@microsoft.com (Greg Stein) Date: Wed, 23 Oct 1996 12:45:23 -0700 Subject: [PYTHON DB-SIG] PATCH for Msql 1.0.16 and Python 1.4b3 Message-ID: Not sure who maintains it. It should say in a README or a header or something. -g -- Greg Stein, Microsoft Corporation execfile("disclaimer.py") >---------- >From: John Mitchell[SMTP:johnm@magnet.com] >Sent: Wednesday, October 23, 1996 10:44 AM >To: db-sig@python.org >Subject: [PYTHON DB-SIG] PATCH for Msql 1.0.16 and Python 1.4b3 > > >Selecting from a table with NULLs results in a coredump from >Python, command-line msql works fine. > >What was happening was that the (antique) msqlmodule was trying to do >newstiringobject(NULL) -- boom! > >This will fix it, around line 207: > >change: > str=newstringobject(thisrow[i]); > >to: > if (!thisrow[i]) { > INCREF(None); > str = None; > } else { > str=newstringobject(thisrow[i]); > } > > >Is anyone maintaining the msqlmodule.c? > >- j > > >John Mitchell my body .. abused. my mind .. unhinged. >Magnet Interactive my reality .. maintained. I am happy. >johnm@magnet.com -- Too Much Coffee Man > > > >================= >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 joe@phoenix.earthlight.co.nz Thu Oct 24 12:38:36 1996 From: joe@phoenix.earthlight.co.nz (Joseph Skinner) Date: Fri, 25 Oct 1996 00:38:36 +1300 Subject: [PYTHON DB-SIG] PyGres with python 1.4b3 Message-ID: <199610241138.AAA00693@pandora.earthlight.co.nz> has anyone had sucess using the PyGres interface to Postgres95 with the current Python beta. When I tried it it failed with code which works correctly with Python 1.3. Comments anyone Joe. ================= 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 Mon Oct 28 16:36:23 1996 From: jim.fulton@digicool.com (Jim Fulton) Date: Mon, 28 Oct 1996 11:36:23 -0500 Subject: [Fwd: [PYTHON DB-SIG] Jim's DBAPI proposelet] References: Message-ID: <3274E107.602E@digicool.com> Michael Lorton wrote: > > >Hi. I sent the attached proposelet a few days ago. Given recent > >discussions, I really thought It would generate some feedback, but > >I haven't heard a peep. This makes me wonder whether people actually > >got the message. If a few of you would just acknowledge this > >note with private mail, I'll know that the communication lines are > >still working. :-) > > > > I didn't see the first copy but maybe that was just me. Points: > > + I don't see how you intend to store prepare statement In prepared-statement objects that are created by invoking a 'prepare' statement on a database (connection) object. > + I don't understand how you distinguish "result set" from cursor (I > mean, I don't see both concepts separately embodied in code) That's the point. Cursors are used in the implementation of result sets, but are not visible in the interface, because they are not interesting. A result table is really a wrapper around a cursor. When a result set is accessed sequentially, the underlying cursor is used to fetch data. If it is desired to get multiple (or all) rows at once, for speed, then a slicing operator may be used. The point is that users of the data don't care about cursors. What they really want is a collection of data. > + I think the datatypes (String, Number, Raw, and Date) are good and we > should keep 'em. Note that these are type 'codes'. Yes, I agree that they are appropriate. Date should be more clearly defined to mean date-time. Also, how are date-time data reflected in Python. This needs to be spelled out too, preferably with a date-time data-type implementation. > + I think the exception model (OpError, ProgError, IntegrityError, > DataError) is good and we should keep it too. What exception model? Where is this defined? Where is it implemented? The oracle module doesn't use these? We need to define how to detect statement (e.g. sql) errors, like syntax errors and name errors. > To defend the last to points: > RDMSs' myriad fine distinctions among types (what is a tinyint vs. a > byte vs. a boolean?) is almost useless (IMHO); I cannot see why exposing > it to the user helps any. > > While the programmer needs access to very specific error messages, the > program cannot be expected to understand the difference between (say) > Database Disconnect and Database Shutdown. High-level catagory are much > more helpful. Right, but the programmer does need to distinguish between Database disconnect and sql syntax errors. We need to define general classes of errors and map database interfaces to them. Some cases I care about include: - How does my application, which maintains long-lived database connections, decide that an error has been raised because the database connection has been lost? How does it decide whether to attempt to reconnect, or to die gracefully? - How does my program detect that a statement entered by a user is bad? Also, how can applications obtain error messages? Are these returned as exception values? Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.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 jim@digicool.com Mon Oct 28 17:49:43 1996 From: jim@digicool.com (Jim Fulton) Date: Mon, 28 Oct 1996 12:49:43 -0500 Subject: [PYTHON DB-SIG] [comp.lang.python] Re: ODBC on pythonwin-10-bx (x in [3,4]) Message-ID: <9610281749.AA12273@ninny.digicool.com> ------- Start of forwarded message ------- From: jim@digicool.com (Jim Fulton) Subject: Re: ODBC on pythonwin-10-bx (x in [3,4]) Newsgroups: comp.lang.python Date: 28 Oct 1996 12:31:45 -0500 Organization: Digital Creations, L.C. Path: news.infi.net!usenet Lines: 35 Sender: jim@ninny.digicool.com Message-ID: References: <199610252313.KAA00882@minotaur.labyrinth.net.au> NNTP-Posting-Host: ninny.digicool.com In-reply-to: "Mark Hammond"'s message of Sat, 26 Oct 1996 00:10:07 GMT X-Newsreader: Gnus v5.1 In article <199610252313.KAA00882@minotaur.labyrinth.net.au> "Mark Hammond" writes: > options checked and an 'import odbc' always gives a "failed to load > DLL" message. We can successfully load modules in the same directory > as odbc.pyd like win32api.pyd, so it's apparently not a PYTHONPATH > problem. I'm also pretty sure that we have all the DLL's set up for > ODBC, since we have a library of Perl scripts running on the same > machine using ODBC. The machine runs NT and has Microsoft SQL Server > v. 6.x installed. Are there any other things to check? We'd really > prefer not to have to use Perl! This is a tiny tiny problem, that we dont know how to fix :-( Use "import dbi" before "import odbc". This explicitely loads the DLL that couldnt be found. This problem also rears it's head on Unix with the dbi and oracle modules. The dbi module seems to be designed to be statically linked into the interpreter, making it hard to use as a dynamically loaded module. I'd like to see dbi redesigned so that it can be used as a dynamically-linked module. In my opinion, this means that other modules, like odbc and oracledb, that want to use dbi should import it and access it's services through exported objects. If it has to export a C interface to other modules, it could do so using C objects (see cobject.h). Looking at how the oracledb module uses dbi, minimal changes should be necessary, and the dbi include file could include some macros to make life easy for the database module developer. -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ------- End of forwarded message ------- ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From jim@digicool.com Mon Oct 28 17:50:54 1996 From: jim@digicool.com (Jim Fulton) Date: Mon, 28 Oct 1996 12:50:54 -0500 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) Message-ID: <9610281750.AA00627@ninny.digicool.com> ------- Start of forwarded message ------- From: jim@digicool.com (Jim Fulton) Subject: Date-Time requirements (esp. for databases) Newsgroups: comp.lang.python Date: 28 Oct 1996 12:49:17 -0500 Organization: Digital Creations, L.C. Path: news.infi.net!usenet Lines: 45 Sender: jim@ninny.digicool.com Message-ID: NNTP-Posting-Host: ninny.digicool.com X-Newsreader: Gnus v5.1 A number of databases support date-time data. It would be helpful to have a standard date-time implementation for use in Python database implementations (and elsewhere, of course). I think that the date-time implementation should: 1. Support conversion from strings in a very wide variety of formats (e.g. 'Oct, 1, 1994 12:34am EST', '1994/10/1 00:34:21.456') 2. Support subtraction of date-times, and addition and subtraction of dates and numbers. 3. Store dates efficiently. 4. Store dates immutably. 5. Represent dates to a specified minimum precision (e.g. milliseconds). 6. Handle all dates in the Gregorian calendar. (e.g. there should not be problems storing dates from the 18th or 21st centurys.) 7. Provide read-access to date-components (e.g. year, month, second, day-of-week, etc.) I'm afraid the implementation should also address issues like: 8. Support for time-zones, 9. Support for daylight-savings time. I have an implementation of date-time data that meets requirements 1-7 and a little of 8, however, this implementation is encumbered and I plan to create a new implementation. If I reimplement my date-time data type, I'd like to do so in a way that is useful to the Python community at large, and to people developing database interfaces in particular. I'm particularly interested in suggestions on whether and how and how much to deal with issues such as time zones and (ugh) daylight-savings time. Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ------- End of forwarded message ------- ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From dan@digicool.com Mon Oct 28 23:23:06 1996 From: dan@digicool.com (Dan Manganelli) Date: Mon, 28 Oct 1996 17:23:06 -0600 Subject: [PYTHON DB-SIG] Oracledb module available Message-ID: <3275405A.7925@digicool.com> The oracledb module is finally available. You can get it at ftp://ftp.digicool.com/pub/releases/oracledb-0.1/oracledb-0.1.tar.gz -- ##################################################### # Daniel F Manganelli || email : dan@digicool.com # # Software Engineer || Digital Creations # ##################################################### ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From cchen@stc.com Tue Oct 29 01:37:03 1996 From: cchen@stc.com (Chris Chen) Date: Mon, 28 Oct 1996 17:37:03 -0800 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) Message-ID: <2.2.32.19961029013703.006b7900@pop.stc.com> In the old Informixdb module I have, both Date and Date-Time data type (they shared the same dbi.DATE type) were converted to standard C time_t value. I can retrieve the time value by using either time.ctime or time.localtime function in the python buildin time module, and the buildin time module actually call the standard C time function. This means they do support the time zone and daylight savings time, but may have difficulty in handling all dates in the Gregorian calendar, or represent the fractional second that exist in some database. Currently, I don't have any problem with using time_t value to represent Date-Time data type, but I will prefer a separate dbi.TIME to deal with the Date-Time data type. Also some enhancement to the buildin time module to include difftime & tzset method would be much appreciated. The more immediate problem is how to represent the DATE type. By converting DATE value to time_t value, it contains more information than it really is which may cause problem in some situation. I also like to know if there is a standard string format for dbi.DATE data type ? Does the DATE format has support for different country (or locale) ? Should we think about a "generic" python Date-Time type to solve all these problem. After all, time is too unigue a concept to treat it causully. I really think most modern language didn't pay enough respect to this forth dimension of the universe. I hope python isn't one of them :-) -Chris Chen At 12:50 PM 10/28/96 -0500, Jim Fulton wrote: >------- Start of forwarded message ------- >From: jim@digicool.com (Jim Fulton) >Subject: Date-Time requirements (esp. for databases) >Newsgroups: comp.lang.python >Date: 28 Oct 1996 12:49:17 -0500 >Organization: Digital Creations, L.C. >Path: news.infi.net!usenet > > >A number of databases support date-time data. It would be helpful to >have a standard date-time implementation for use in Python database >implementations (and elsewhere, of course). > >I think that the date-time implementation should: > > 1. Support conversion from strings in a very wide variety of formats > (e.g. 'Oct, 1, 1994 12:34am EST', '1994/10/1 00:34:21.456') > > 2. Support subtraction of date-times, and addition and > subtraction of dates and numbers. > > 3. Store dates efficiently. > > 4. Store dates immutably. > > 5. Represent dates to a specified minimum precision > (e.g. milliseconds). > > 6. Handle all dates in the Gregorian calendar. (e.g. there should > not be problems storing dates from the 18th or 21st centurys.) > > 7. Provide read-access to date-components (e.g. year, month, second, > day-of-week, etc.) > >I'm afraid the implementation should also address issues like: > > 8. Support for time-zones, > > 9. Support for daylight-savings time. > >I have an implementation of date-time data that meets requirements >1-7 and a little of 8, however, this implementation is encumbered and >I plan to create a new implementation. If I reimplement my date-time >data type, I'd like to do so in a way that is useful to the Python >community at large, and to people developing database interfaces in >particular. I'm particularly interested in suggestions on whether and >how and how much to deal with issues such as time zones and (ugh) >daylight-savings time. > ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From Anthony Baxter Tue Oct 29 03:50:26 1996 From: Anthony Baxter (Anthony Baxter) Date: Tue, 29 Oct 1996 14:50:26 +1100 Subject: [PYTHON DB-SIG] Re: Oracledb Module Available In-Reply-To: Your message of "Mon, 28 Oct 1996 22:21:08 GMT." <32753109.80482758@news.infi.net> References: <32753109.80482758@news.infi.net> Message-ID: <199610290350.OAA01773@jambu.off.connect.com.au> (for anyone else who is having problems - the ftp.digicool.com server doesn't seem to like PASV ftp connections...) >>> Daniel F Manganelli wrote > The oracledb module is finally available. You can get it at > > ftp://ftp.digicool.com/pub/releases/oracledb-0.1/oracledb-0.1.tar.gz Ok, I'm just starting out with this (we've been using Oraperl until now, I hate it, lots). The first thing that's stumped me is 'what on earth is the format for the connection string?' The doc string sez: "This method begins the oracle session. It must be passed your logon information in the form of a string. EX: oracledb('usernamepassword')" say I have dbuser@dbhost, password is dbpasswd. I've tried dbuser@dbhost - gives 'logon/passwd incorrect' dbuserdbpasswd@dbhost - gives 'logon/passwd incorrect' dbuser:dbpasswd@dbhost - gives 'logon/passwd incorrect' dbuser@dbhost:dbpasswd - gives 'invalid driver designator' and other variations on the theme. Help! (Yes, we have Oracle docs. One of the contractors here has borrowed them :( On another note, the DB-SIG API is version 1.0 - is this the same API that the oracledb module is on? ta, Anthony ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From Anthony Baxter Tue Oct 29 04:26:56 1996 From: Anthony Baxter (Anthony Baxter) Date: Tue, 29 Oct 1996 15:26:56 +1100 Subject: [PYTHON DB-SIG] Re: Oracledb Module Available In-Reply-To: Your message of "Tue, 29 Oct 1996 14:50:26 +1100." <199610290350.OAA01773@jambu.off.connect.com.au> References: <199610290350.OAA01773@jambu.off.connect.com.au> <32753109.80482758@news.infi.net> Message-ID: <199610290426.PAA01941@jambu.off.connect.com.au> >>> Anthony Baxter wrote > Ok, I'm just starting out with this (we've been using Oraperl until now, > I hate it, lots). The first thing that's stumped me is 'what on earth is > the format for the connection string?' Ok, I found it by doing a strings on lots of things. it's dbuser/dbpasswd@dbhost. Sorry for the interruption... Anthony *** ../oracledb-0.1/oradbmodule.c Sat Oct 26 06:14:27 1996 --- ./oradbmodule.c Tue Oct 29 15:25:12 1996 *************** *** 786,792 **** } static char oraLogon__doc__[] = ! "This method begins the oracle session. It must be passed your logon information in the form of a string. EX: oracledb('usernamepassword')" ; static PyObject *oraLogon(PyObject *self, PyObject *args) --- 786,792 ---- } static char oraLogon__doc__[] = ! "This method begins the oracle session. It must be passed your logon information in the form of a string. EX: oracledb('username/password@host')" ; static PyObject *oraLogon(PyObject *self, PyObject *args) ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From hiren@dnaco.net Tue Oct 29 07:00:25 1996 From: hiren@dnaco.net (Hirendra Hindocha) Date: Tue, 29 Oct 1996 02:00:25 -0500 Subject: [PYTHON DB-SIG] recent postings and table classes Message-ID: <1.5.4.32.19961029070025.002cd820@kirk.dnaco.net> --=====================_846590425==_ Content-Type: text/plain; charset="us-ascii" Hmm, I don't have access to the recent postings on the db-sig (i.e not from home) but the general talk has been about wrapper classes to table and a row. I have been working on displaying data from a RDBMS using the odbc module. The original idea was to provide base wrapper classes around the table and a row from other classes will derive to provide app specific functionality. This instances could then be passed off to the HTMLgen.Table class which expects a list of lists to format and display. The idea was to retrieve a row just when needed (didn't quite work out because of string.join inability to handle an instance instead of a sequence or a list) and here is some preliminary work done that I've attached. suggestions are most welcome. Hiren --------------------------------cut here ---------------------------- --=====================_846590425==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="Database.py" # $Id: Database.py,v 1.1 1996/10/28 03:33:27 hiren Exp hiren $ # $Author: hiren $ # vim:ts=2:sw=2 import dbi import odbc import time class RTable: def __init__(self,dsn): try: s = odbc.odbc(dsn) self.cur = s.cursor() except NameError,e: print 'error ', e, 'undefined' def execute(sql): self.sql = sql try: self.cur.execute(self.sql) except NameError,e: print 'error ', e, 'undefined' def __len__(self): pass def __setitem__(self,key,val): pass def __getitem__(self,index): rec = self.cur.fetchone() if not rec: raise IndexError, "index too large" return rec class RRec: def __init__(self,rec,description): self.record = [] if not rec: return i = 0 for field in rec: if description[i][1] == 'DATE': #print description[i][1],field,field.value if field != None and field != 'N/A': local = time.localtime(field.value) s = str(local[1]) + '/' \ + str(local[2]) + '/' +str(local[0]) setattr(self,description[i][0],s) self.record.append(s) else: self.record.append('N/A') elif description[i][1] == 'RAW': dummy = 'RAW Not Implemented' setattr(self,description[i][0],dummy) self.record.append( dummy) else: setattr(self,description[i][0],field) self.record.append(field) i = i+1 self.data = self.record def dump(self): for i in self: print i, print def __len__(self): return len(self.record) def __setitem__(self,key,val): self.record[key] = val def __getitem__(self,index): return self.record[index] if __name__ == '__main__': print 'script as main' #sqlstmt = 'select * from shippers' #sqlstmt = 'select * from orders' #sqlstmt = 'select * from categories' # sqlstmt = '\ # SELECT Employees.EmployeeID, Employees.LastName,\ # Employees.FirstName, Employees.Title, Employees.TitleOfCourtesy,\ # Employees.BirthDate, Employees.HireDate, Employees.Address,\ # Employees.City, Employees.Region, Employees.PostalCode,\ # Employees.Country,\ # Employees.HomePhone, Employees.Extension, Employees.Notes,\ # Employees.ReportsTo\ # FROM Employees' sqlstmt = '\ SELECT EmployeeID, LastName,\ FirstName, Title, TitleOfCourtesy,\ City, Region, PostalCode,\ Country,\ HireDate, Address,\ HomePhone, Extension, Notes,\ ReportsTo\ FROM Employees' dsn='nwin/admin/' s = RTable(dsn,sqlstmt) #print s.cur.description for rec in s: b = RRec(rec,s.cur.description) for field in b: print field, print --=====================_846590425==_ Content-Type: text/plain; charset="us-ascii" --=====================_846590425==_-- ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From flognat@fukt.hk-r.se Tue Oct 29 09:52:58 1996 From: flognat@fukt.hk-r.se (Andy Eskilsson) Date: 29 Oct 1996 10:52:58 +0100 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: Jim Fulton's message of Mon, 28 Oct 1996 12:50:54 -0500 References: <9610281750.AA00627@ninny.digicool.com> Message-ID: / Jim Fulton wrote: | | 1. Support conversion from strings in a very wide variety of formats | (e.g. 'Oct, 1, 1994 12:34am EST', '1994/10/1 00:34:21.456') Thats what I have created my strptime function to do, you can find it at: http://www.fukt.hk-r.se/~flognat/hacks/, the inverse of strftime. | 9. Support for daylight-savings time. In what way should this be done, when converting from local time to GMT or? That will need a database :-) I mean whe have just moved the switching from summertime to wintertime one month, here in sweden.. /Andy -- Hi I am an alien .sig, and at the moment I am having sex to your mind, by looking at your smile I can see that you like it. Unsolicited commercial email is subject to an archival fee of $400. See for more info. ================= 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 Tue Oct 29 16:04:44 1996 From: jim.fulton@digicool.com (Jim Fulton) Date: Tue, 29 Oct 1996 11:04:44 -0500 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) References: <9610281750.AA00627@ninny.digicool.com> Message-ID: <32762B1C.3C17@digicool.com> Andy Eskilsson wrote: > > / Jim Fulton wrote: > | > | 1. Support conversion from strings in a very wide variety of formats > | (e.g. 'Oct, 1, 1994 12:34am EST', '1994/10/1 00:34:21.456') > > Thats what I have created my strptime function to do, you can find it > at: http://www.fukt.hk-r.se/~flognat/hacks/, the inverse of strftime. This looks good, but I want something that doesn't require a format string. > | 9. Support for daylight-savings time. > > In what way should this be done, when converting from local time to > GMT or? That will need a database :-) I mean whe have just moved the > switching from summertime to wintertime one month, here in sweden.. Right. Daylight-savings time introduces some definite complexities. Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.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 pa@tekla.fi Tue Oct 29 21:09:34 1996 From: pa@tekla.fi (Harri Pasanen) Date: Tue, 29 Oct 1996 23:09:34 +0200 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: <32762B1C.3C17@digicool.com> References: <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> Message-ID: <9610292109.AA24803@tahma.tekla.fi> Jim Fulton writes: > Andy Eskilsson wrote: > > > > / Jim Fulton wrote: > > | > > | 1. Support conversion from strings in a very wide variety of formats > > | (e.g. 'Oct, 1, 1994 12:34am EST', '1994/10/1 00:34:21.456') > > > > Thats what I have created my strptime function to do, you can find it > > at: http://www.fukt.hk-r.se/~flognat/hacks/, the inverse of strftime. > > This looks good, but I want something that doesn't require a format > string. What are you thinking of? How do you plan to achieve genericity without some kind of template, or format string? Or are you planning to hide the possible format strings/templates inside the a Date object factory, which returns a Date object when receiving the string representation? Just curious, Harri ================= 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 Tue Oct 29 22:39:01 1996 From: jim.fulton@digicool.com (Jim Fulton) Date: Tue, 29 Oct 1996 17:39:01 -0500 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) References: <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> Message-ID: <32768785.7F51@digicool.com> Harri Pasanen wrote: > > Jim Fulton writes: > > Andy Eskilsson wrote: > > > > > > / Jim Fulton wrote: > > > | > > > | 1. Support conversion from strings in a very wide variety of formats > > > | (e.g. 'Oct, 1, 1994 12:34am EST', '1994/10/1 00:34:21.456') > > > > > > Thats what I have created my strptime function to do, you can find it > > > at: http://www.fukt.hk-r.se/~flognat/hacks/, the inverse of strftime. > > > > This looks good, but I want something that doesn't require a format > > string. > > What are you thinking of? How do you plan to achieve genericity > without some kind of template, or format string? Yes. I've done this before. It's not practical unless it is done in C. In this case, I'd be inclined to provide handling of a very wide variety of formats without requiring format strings, but allow the specification of format strings as well. > Or are you planning to hide the possible format strings/templates > inside the a Date object factory, which returns a Date object when > receiving the string representation? I want a constructor something like this: DateTime(*args) -- Return a new date-time object This function may be invoked with from zero to six arguments. If the function is called with no arguments, then the current date and time is returned. If the function is invoked with a single string argument, then the string is parsed as a date-time value. If the string contains a valid date-time value, then the corresponding date-time object is returned, otherwise a DateTime.error is raised. As a general rule, any date-time representation that is recognized and unambigous to a human is acceptable. A date-time string consists of two components, a date component and an optional time component, separated by one or more spaces. If the time component is ommited, 12:00am is assumed. The date component consists of year, month, and day values. The year value must be a two- or four-digit integer. If a two-digit year is used, the year is assumed to be in the twentieth century. The month may an integer, from 1 to 12, a month name, or a month abreviation, where a period may optionally follow the abreviation. The day must be an integer from 1 to the number of days in the month. The year, month, and day values may be separated by periods, hyphens, forward, shashes, underscores, or spaces. Extra spaces are permitted around the delimiters. Year, month, and day values may be given in any order as long as it is possible to distinguish the components. If all three components are numbers that are less than 13, then a a month-day-year ordering is assumed. The time component consists of hour, minute, and second values separated by colons. The hour value must be an integer between 0 and 23 inclusively. The minute value must be an integer between 0 and 59 inclusively. The second value may be an integer value between 0 and 59.999 inclusively. The second value or both the minute and second values may be ommitted. The time may be followed by am or pm in upper or lower case, in which case a 12-hour clock is assumed. If the DateTime function is invoked with two string arguments, then the first argument is treated as a format string and the second argument is parsed as a date-time value according to the format string. If the DateTime function is invoked with a single Numeric argument, then a DateTime object is returned that is that number of days after January 1, 1900. A negative argument will yield a date-time value before 1900. If the function is invoked with two numeric arguments, then the first is taken to be an integer year, the second argument is taken to be an offset in days from the beginning of the year, and the date-time value returned is the given offset number of days from the beginning of the givem year. The offset may be positive or negative. This form of the function is commonly used to convert a year and julean day to a date-time value. Two-digit years are assumed to be in the twentieth century. If the function is invoked with three or more numeric arguments, then the first is taken to be an integer year, the second is taken to be an integer month, and the third is taken to be an integer day. If the combination of values is not valid, then a DateTime.error is raised. Two-digit years are assumed to be in the twentieth century. The fourth, fifth, and sixth arguments are floating point, positive or negative offsets in units of hours, minutes, and days, and default to zero if not given. The date returned is the date-time object corresponding to the given year, month, and day, offset by the given hours, minutes, and seconds. The description above is from my current DateTime module, except that I've added provision for an optional format string. My thought is that there would be a DateTime class that would be called to create instances as described above. Data such as month and day names would be stored in dictionaries as class attributes that could be replaced with locale-specific values. > ================= > DB-SIG - SIG on Tabular Databases in Python > > send messages to: db-sig@python.org > administrivia to: db-sig-request@python.org > ================= -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.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 Anthony Baxter Wed Oct 30 01:10:00 1996 From: Anthony Baxter (Anthony Baxter) Date: Wed, 30 Oct 1996 12:10:00 +1100 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: Your message of "Tue, 29 Oct 1996 17:39:01 CDT." <32768785.7F51@digicool.com> References: <32768785.7F51@digicool.com> <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> Message-ID: <199610300110.MAA04639@jambu.off.connect.com.au> > > What are you thinking of? How do you plan to achieve genericity > > without some kind of template, or format string? > > Yes. I've done this before. It's not practical unless it is > done in C. For an example of a way of doing this, check Perl5's Date::Manip package - it's kinda neat (although sloooow). The hassle with providing default ways of converting is that it leads people to expect you to be able to deal with anything. I was bitten by this recently - a cisco generated dates like "29 Oct 1996 UTC 11:57:23" and the UTC bit broke the ParseDate function. > In this case, I'd be inclined to provide handling of a very > wide variety of formats without requiring format strings, > but allow the specification of format strings as well. (Rather than/as well as) a format string, I'd like to see the ability to provide a regexp with symbolic group names for getting the dates out. This is a bit more powerful - you can deal with virtually anything then :) Perhaps we can provide a collection of standard ones... > If the function is invoked with a single string argument, then the > string is parsed as a date-time value. If the string contains a valid > date-time value, then the corresponding date-time object is returned, > otherwise a DateTime.error is raised. As a general rule, any date-time > representation that is recognized and unambigous to a human is "unambiguous" is a problem. What's 03/06/96 represent? 3rd June, or 6th March? Date::Manip has an option you set for US mode (M/D/Y), or everywhere else (D/M/Y) mode. > acceptable. A date-time string consists of two components, a date > component and an optional time component, separated by one or more > spaces. If the time component is ommited, 12:00am is assumed. I'd also like the ability to just give it an int from time.time(), but that may be just my unix bias showing. I'd be happy with just DateTime("1 Jan 1970 00:00:00 UTC") + DateTime("%d seconds"%time.time()). > long as it is possible to distinguish the components. If all three > components are numbers that are less than 13, then a a month-day-year > ordering is assumed. I have a problem with this default (see above) - it should be selectable. Rather than having behaviour depend on the number of arguments (which means people are going to be running for the docs far far too often), why not use keywords? DateTime.DateTime(year=1996, day=200) DateTime.DateTime(year=1996, month=5, day=20) > The description above is from my current DateTime module, except that > I've added provision for an optional format string. > > My thought is that there would be a DateTime class that would be > called to create instances as described above. Data such as > month and day names would be stored in dictionaries as class attributes > that could be replaced with locale-specific values. Other methods the DateTime objects should have: strftime - takes a format string, returns the date as a string in the specified format. ("%Y%M%D %H:%M:%S" -> "19961029 11:57:00") arithmetic - difference between two dates. adding dates - it should be possible to produce a DateTime object representing "1 week" and say DateTime(now) + DateTime("1 week"). conversion to/from dbiDate objects. Timezones. If the OS supports timezones, it should use it. Yes, this incurs some portability hassles, but that's the way things are - under Unix, the timezone support is very good, and should be used. If Windows or whatever has inadequate support for timezones, then something else should be provided for that. Hardcoding timezones is something that should be avoided. Particularly with daylight savings, which is a hideous political issue. Australia has 8 states and territories - nearly every one of these has different timezone/DST rules. Anthony ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From ct7@kaizen.net Wed Oct 30 03:23:06 1996 From: ct7@kaizen.net (W. Craig Trader) Date: Tue, 29 Oct 1996 22:23:06 -0500 (EST) Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: <199610300110.MAA04639@jambu.off.connect.com.au> Message-ID: On Wed, 30 Oct 1996, Anthony Baxter wrote: > Other methods the DateTime objects should have: > > strftime - takes a format string, returns the date as a string in the > specified format. ("%Y%M%D %H:%M:%S" -> "19961029 11:57:00") This is good, though it duplicates the existing `time' modules function. > arithmetic - difference between two dates. adding dates - it should be > possible to produce a DateTime object representing "1 week" > and say DateTime(now) + DateTime("1 week"). I think you're wrong here - there should be multiple types: DateTime, as already discussed, and Interval, which would represent a signed quantity of a generic unit (ie: 10 minutes or 2 hours or 1 week or 5 years), or possibly a combination. Math would look like this: Interval + Interval => Interval Interval - Interval => Inverval DateTime + Interval => DateTime DateTime - Interval => DateTime DateTime - DateTime => Interval Since we're talking about databases, the types should try to stick fairly close to SQL, and SQL/92 already has provisions for DateTimes and Intervals. > Timezones. If the OS supports timezones, it should use it. Yes, this incurs > some portability hassles, but that's the way things are - under Unix, the > timezone support is very good, and should be used. If Windows or whatever > has inadequate support for timezones, then something else should be provided > for that. Again, I'd want to look towards SQL for this type of problem - the theory's probably already been solved - why work hard only to produce something that isn't compatible with major databases? > Hardcoding timezones is something that should be avoided. Particularly with > daylight savings, which is a hideous political issue. Australia has 8 states > and territories - nearly every one of these has different timezone/DST rules. Well, at least South Australia is no longer 1.5 hours off from Queensland. That was a *real* lousy system. Of course, Indiana in the States is the worst - it varies county by county. - Craig - ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From Anthony Baxter Wed Oct 30 04:09:08 1996 From: Anthony Baxter (Anthony Baxter) Date: Wed, 30 Oct 1996 15:09:08 +1100 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: Your message of "Tue, 29 Oct 1996 22:23:06 CDT." Message-ID: <199610300409.PAA05150@jambu.off.connect.com.au> >>> "W. Craig Trader" wrote > > [strftime] > This is good, though it duplicates the existing `time' modules function. Yes, but can the existing function handle DateTime objects? It shouldn't have to, a > > [arithmetic] > I think you're wrong here - there should be multiple types: DateTime, as > already discussed, and Interval, which would represent a signed quantity > of a generic unit (ie: 10 minutes or 2 hours or 1 week or 5 years), or > possibly a combination. Math would look like this: Sounds good to me! > Since we're talking about databases, the types should try to stick fairly > close to SQL, and SQL/92 already has provisions for DateTimes and > Intervals. If anyone can point me to a good source of info about SQL, it would be appreciated (online would be even better! :) > > [timezones] > Again, I'd want to look towards SQL for this type of problem - the > theory's probably already been solved - why work hard only to produce > something that isn't compatible with major databases? If SQL does it, and does it _right_, then fine, otherwise, no. Correctness is more important for my purposes than compatibility with databases (which are likely to each implement everything slightly differently, anyway :( > Well, at least South Australia is no longer 1.5 hours off from Queensland. > That was a *real* lousy system. Of course, Indiana in the States is the > worst - it varies county by county. No, instead we have, at the moment: Vic, NSW, Tas, Canberra: UTC+11 (Tas, Vic, NSW/ACT all have different start/end times for DST) QLD: UTC+10 (no DST) SA: UTC+10.5 (DST, normally 1/2 hour behind Eastern states) NT: UTC+9.5 (no DST, normally 1/2 hour behind Eastern states) WA: UTC+8 (no DST, normally 2 hours behind Eastern states) Currently we don't have any boxes in the Northern Territory (yet :( ) but I have to worry about everywhere else. Guess why I care about timezones... :-/ I'd imagine places in the US are similarly horrid. Anthony ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From per@tekla.fi Wed Oct 30 11:23:22 1996 From: per@tekla.fi (Petri Raitio) Date: Wed, 30 Oct 1996 13:23:22 +0200 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: <32768785.7F51@digicool.com> References: <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> <32768785.7F51@digicool.com> Message-ID: <9610301123.AA19322@kitty.tekla.fi> "Jim" =3D=3D Jim Fulton writes: Jim> I want a constructor something like this: Jim> DateTime(*args) -- Return a new date-time object This is great, I'd love to give up maintaining My Own Date module! = Jim> The date component consists of year, month, and day values. The Jim> year value must be a two- or four-digit integer. If a two-digit Jim> year is used, the year is assumed to be in the twentieth Jim> century. The month may an integer, from 1 to 12, a month name, Jim> or a month abreviation, where a period may optionally follow Jim> the abreviation. The day must be an integer from 1 to the Jim> number of days in the month. The year, month, and day values Jim> may be separated by periods, hyphens, forward, shashes, Jim> underscores, or spaces. Extra spaces are permitted around the Jim> delimiters. Year, month, and day values may be given in any Jim> order as long as it is possible to distinguish the components. Jim> If all three components are numbers that are less than 13, then Jim> a a month-day-year ordering is assumed. I'd like to have less chance for misunderstanding here. I think there should be a default format with a *fixed* DMY order, so that I could tell the user that 10.30.1996 is not a valid (European) date. I wonder if it would make sense to use the separator as a format specifier and have format-specific DMY orders, so that 10/30/1996 and 30.10.1996 would be valid dates but 30/10/1996 and 10.30.1996 would not. This way, it would be easy for us Europeans to specify a native format date in a program written in the US. Jim> The time component consists of hour, minute, and second values Jim> separated by colons. The hour value must be an integer between Jim> 0 and 23 inclusively. The minute value must be an integer Jim> between 0 and 59 inclusively. The second value may be an Jim> integer value between 0 and 59.999 inclusively. My crazy ctime(3) man page tells me seconds are in the range [0, 60], and the ANSI C standard makes this a bit crazier, [0, 61]! These are a provision for leap seconds, up to two of them. But maybe we don't really care to be *that* precise, I'm sure nobody's localtime() will actually return them.. Jim> If the DateTime function is invoked with two string arguments, Jim> then the first argument is treated as a format string and the Jim> second argument is parsed as a date-time value according to the Jim> format string. Just a detail: wouldn't this be nicer the other way around, as in foo(str, fmt =3D "")? = Jim> Two-digit years are assumed to be in the twentieth century. This definition will become obsolete in a few years! Did you mean in the *current* century? Jim> Data such as month and day names would be stored in dictionaries Jim> as class attributes that could be replaced with locale-specific Jim> values. Fine, this is absolutely required! Note, that the system locale is not very useful, so the strings need to come from the module that uses the Date module. (I don't want my 'ls' to tell me a file is dated '30 Loka' when it is really 'Oct 30'.) I would also like to see operations for inquiring week number and day-of-week information; I have a week number algorithm that returns correct week numbers according to the definition here in Finland, but I'm not sure how universal this is. (Weeks start with Monday; the first Friday in January is always on week 1; thus the week number can run up to 53, the last week in a year can be number 1 from the next year, and the first week can be 52 or 53 from the previous year.) ================= 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 Oct 30 12:56:30 1996 From: jim.fulton@digicool.com (Jim Fulton) Date: Wed, 30 Oct 1996 07:56:30 -0500 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) References: <32768785.7F51@digicool.com> <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> <199610300110.MAA04639@jambu.off.connect.com.au> Message-ID: <3277507E.7948@digicool.com> Anthony Baxter wrote: > > > > What are you thinking of? How do you plan to achieve genericity > > > without some kind of template, or format string? > > > > Yes. I've done this before. It's not practical unless it is > > done in C. > > For an example of a way of doing this, check Perl5's Date::Manip > package - it's kinda neat (although sloooow). > The hassle with providing default ways of converting is that it leads > people to expect you to be able to deal with anything. I was bitten by > this recently - a cisco generated dates like "29 Oct 1996 UTC 11:57:23" > and the UTC bit broke the ParseDate function. This is a valid point, however, I have used this approach to date-time data in software for several years and have found the approach to be quite robust if the underlying date parsing software is. Of course, if a programmer doesn't want to trust this approach, they can use a format string. > > > In this case, I'd be inclined to provide handling of a very > > wide variety of formats without requiring format strings, > > but allow the specification of format strings as well. > > (Rather than/as well as) a format string, I'd like to see the ability to > provide a regexp with symbolic group names for getting the dates out. > This is a bit more powerful - you can deal with virtually anything then :) > > Perhaps we can provide a collection of standard ones... > > > If the function is invoked with a single string argument, then the > > string is parsed as a date-time value. If the string contains a valid > > date-time value, then the corresponding date-time object is returned, > > otherwise a DateTime.error is raised. As a general rule, any date-time > > representation that is recognized and unambigous to a human is > > "unambiguous" is a problem. What's 03/06/96 represent? 3rd June, or > 6th March? Date::Manip has an option you set for US mode (M/D/Y), or > everywhere else (D/M/Y) mode. This is a good idea. Is the US the only place that favors M/D/Y? > > acceptable. A date-time string consists of two components, a date > > component and an optional time component, separated by one or more > > spaces. If the time component is ommited, 12:00am is assumed. > > I'd also like the ability to just give it an int from time.time(), but > that may be just my unix bias showing. I'd be happy with just > > DateTime("1 Jan 1970 00:00:00 UTC") + DateTime("%d seconds"%time.time()). See below. > > long as it is possible to distinguish the components. If all three > > components are numbers that are less than 13, then a a month-day-year > > ordering is assumed. > > I have a problem with this default (see above) - it should be selectable. Agreed. > Rather than having behaviour depend on the number of arguments (which means > people are going to be running for the docs far far too often), why not use > keywords? > > DateTime.DateTime(year=1996, day=200) > DateTime.DateTime(year=1996, month=5, day=20) I agree that keywords should work *too*. > > The description above is from my current DateTime module, except that > > I've added provision for an optional format string. > > > > My thought is that there would be a DateTime class that would be > > called to create instances as described above. Data such as > > month and day names would be stored in dictionaries as class attributes > > that could be replaced with locale-specific values. > > Other methods the DateTime objects should have: > > strftime - takes a format string, returns the date as a string in the > specified format. ("%Y%M%D %H:%M:%S" -> "19961029 11:57:00") Good. > arithmetic - difference between two dates. adding dates - it should be > possible to produce a DateTime object representing "1 week" > and say DateTime(now) + DateTime("1 week"). > > conversion to/from dbiDate objects. Of course. > Timezones. If the OS supports timezones, it should use it. Yes, this incurs > some portability hassles, but that's the way things are - under Unix, the > timezone support is very good, and should be used. If Windows or whatever > has inadequate support for timezones, then something else should be provided > for that. Agreed. > Hardcoding timezones is something that should be avoided. Particularly with > daylight savings, which is a hideous political issue. Australia has 8 states > and territories - nearly every one of these has different timezone/DST rules. I agree. Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.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 jim.fulton@digicool.com Wed Oct 30 13:09:05 1996 From: jim.fulton@digicool.com (Jim Fulton) Date: Wed, 30 Oct 1996 08:09:05 -0500 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) References: <32768785.7F51@digicool.com> <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> <199610300110.MAA04639@jambu.off.connect.com.au> Message-ID: <32775371.35AE@digicool.com> Anthony Baxter wrote: > > arithmetic - difference between two dates. adding dates - it should be > possible to produce a DateTime object representing "1 week" > and say DateTime(now) + DateTime("1 week"). Oops. In my earlier note I agreed with this without reading it carefully enough. DateTime("1 week") doesn't make any sense to me. DateTime objects refer to specific points in time, not time units. I think that DateTime objects should support addition/subtraction of numbers to/from date-time objects. I think we should decide what units are used for this. IMO the units should be either days or seconds. I'd vote for days myself, but I could live with seconds. In addition, the DateTime class should have attributes that give the lengths of various units of time. Perhaps these attributes should be: lengthOfYear(year), lengthOfMonth(year,month), lengthOfWeek, lengthOfDay, lengthOfHour, lengthOfMinute, lengthOfSecond. So the above expression would become: DateTime(now) + DateTime.lengthOfWeek Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.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 jim.fulton@digicool.com Wed Oct 30 13:14:04 1996 From: jim.fulton@digicool.com (Jim Fulton) Date: Wed, 30 Oct 1996 08:14:04 -0500 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) References: Message-ID: <3277549C.F10@digicool.com> W. Craig Trader wrote: > > On Wed, 30 Oct 1996, Anthony Baxter wrote: > > > Other methods the DateTime objects should have: > > > > strftime - takes a format string, returns the date as a string in the > > specified format. ("%Y%M%D %H:%M:%S" -> "19961029 11:57:00") > > This is good, though it duplicates the existing `time' modules function. > > > arithmetic - difference between two dates. adding dates - it should be > > possible to produce a DateTime object representing "1 week" > > and say DateTime(now) + DateTime("1 week"). > > I think you're wrong here - there should be multiple types: DateTime, as > already discussed, and Interval, which would represent a signed quantity > of a generic unit (ie: 10 minutes or 2 hours or 1 week or 5 years), or > possibly a combination. Math would look like this: > > Interval + Interval => Interval > Interval - Interval => Inverval > DateTime + Interval => DateTime > DateTime - Interval => DateTime > DateTime - DateTime => Interval > > Since we're talking about databases, the types should try to stick fairly > close to SQL, and SQL/92 already has provisions for DateTimes and > Intervals. What is the rational for using a dedicated Interval class rather than just using numbers with agreed units. (See my other note?) Is the benefit worth the added class? > > > Timezones. If the OS supports timezones, it should use it. Yes, this incurs > > some portability hassles, but that's the way things are - under Unix, the > > timezone support is very good, and should be used. If Windows or whatever > > has inadequate support for timezones, then something else should be provided > > for that. > > Again, I'd want to look towards SQL for this type of problem - the > theory's probably already been solved - why work hard only to produce > something that isn't compatible with major databases? My inclination is to leave this issue somewhat open. I'm going to propose that Date-Time objects have optional time-zone attributes that may be bound to time-zone objects that can convert from a base time (e.g. GMT) to "local" time and make the implementation of time-zone objects independent of the implementation of date-time objects. > > Hardcoding timezones is something that should be avoided. Particularly with > > daylight savings, which is a hideous political issue. Australia has 8 states > > and territories - nearly every one of these has different timezone/DST rules. > > Well, at least South Australia is no longer 1.5 hours off from Queensland. > That was a *real* lousy system. Of course, Indiana in the States is the > worst - it varies county by county. Hee hee. Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.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 jim.fulton@digicool.com Wed Oct 30 13:24:27 1996 From: jim.fulton@digicool.com (Jim Fulton) Date: Wed, 30 Oct 1996 08:24:27 -0500 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) References: <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> <32768785.7F51@digicool.com> <9610301123.AA19322@kitty.tekla.fi> Message-ID: <3277570B.4BD6@digicool.com> Petri Raitio wrote: > > "Jim" == Jim Fulton writes: > > Jim> I want a constructor something like this: > > Jim> DateTime(*args) -- Return a new date-time object > > This is great, I'd love to give up maintaining My Own Date module! > > Jim> The date component consists of year, month, and day values. The > Jim> year value must be a two- or four-digit integer. If a two-digit > Jim> year is used, the year is assumed to be in the twentieth > Jim> century. The month may an integer, from 1 to 12, a month name, > Jim> or a month abreviation, where a period may optionally follow > Jim> the abreviation. The day must be an integer from 1 to the > Jim> number of days in the month. The year, month, and day values > Jim> may be separated by periods, hyphens, forward, shashes, > Jim> underscores, or spaces. Extra spaces are permitted around the > Jim> delimiters. Year, month, and day values may be given in any > Jim> order as long as it is possible to distinguish the components. > Jim> If all three components are numbers that are less than 13, then > Jim> a a month-day-year ordering is assumed. > > I'd like to have less chance for misunderstanding here. I think there > should be a default format with a *fixed* DMY order, so that I could > tell the user that 10.30.1996 is not a valid (European) date. I think that this should be an option. That is, the programmer should have a flag, or perhaps a subclass, that enforces rules like you just mentioned. > > I wonder if it would make sense to use the separator as a format > specifier and have format-specific DMY orders, so that 10/30/1996 and > 30.10.1996 would be valid dates but 30/10/1996 and 10.30.1996 would > not. This way, it would be easy for us Europeans to specify a native > format date in a program written in the US. This is an interesting idea. Is the correlation between delimiter and order really that strong? > Jim> The time component consists of hour, minute, and second values > Jim> separated by colons. The hour value must be an integer between > Jim> 0 and 23 inclusively. The minute value must be an integer > Jim> between 0 and 59 inclusively. The second value may be an > Jim> integer value between 0 and 59.999 inclusively. > > My crazy ctime(3) man page tells me seconds are in the range [0, 60], > and the ANSI C standard makes this a bit crazier, [0, 61]! These are > a provision for leap seconds, up to two of them. But maybe we don't > really care to be *that* precise, I'm sure nobody's localtime() will > actually return them.. Does anyone (in this discussion) know the rules for leap seconds? > Jim> If the DateTime function is invoked with two string arguments, > Jim> then the first argument is treated as a format string and the > Jim> second argument is parsed as a date-time value according to the > Jim> format string. > > Just a detail: wouldn't this be nicer the other way around, as in > foo(str, fmt = "")? I don't have a strong opinion on this. I was just following hysterical conventions (e.g. scanf). > Jim> Two-digit years are assumed to be in the twentieth century. > > This definition will become obsolete in a few years! Did you mean in > the *current* century? Actually, the "current" century definition would be very dangerous. There are alot of data sets that use 2-digit years and all of these would break on Jan 1, 2000 if a "current" century definition was used. > Jim> Data such as month and day names would be stored in dictionaries > Jim> as class attributes that could be replaced with locale-specific > Jim> values. > > Fine, this is absolutely required! Note, that the system locale is > not very useful, so the strings need to come from the module that uses > the Date module. (I don't want my 'ls' to tell me a file is dated > '30 Loka' when it is really 'Oct 30'.) > > I would also like to see operations for inquiring week number and > day-of-week information; I have a week number algorithm that returns > correct week numbers according to the definition here in Finland, but > I'm not sure how universal this is. (Weeks start with Monday; the > first Friday in January is always on week 1; thus the week number can > run up to 53, the last week in a year can be number 1 from the next > year, and the first week can be 52 or 53 from the previous year.) I've done day-of-week in the past. Week number is an interesting idea, but it sounds like it lacks a universal definition. Note that the DateTime class (whether implemented in C or Python) will be subclassable so perhaps features like "week number" should be defered to subclasses. Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.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 pa@tekla.fi Wed Oct 30 13:35:03 1996 From: pa@tekla.fi (Harri Pasanen) Date: Wed, 30 Oct 1996 15:35:03 +0200 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: <3277549C.F10@digicool.com> References: <3277549C.F10@digicool.com> Message-ID: <9610301335.AA05042@tahma.tekla.fi> Jim Fulton writes: > W. Craig Trader wrote: > > > > On Wed, 30 Oct 1996, Anthony Baxter wrote: > > > > > Other methods the DateTime objects should have: > > > > > > strftime - takes a format string, returns the date as a string in the > > > specified format. ("%Y%M%D %H:%M:%S" -> "19961029 11:57:00") > > > > This is good, though it duplicates the existing `time' modules function. > > > > > arithmetic - difference between two dates. adding dates - it should be > > > possible to produce a DateTime object representing "1 week" > > > and say DateTime(now) + DateTime("1 week"). > > > > I think you're wrong here - there should be multiple types: DateTime, as > > already discussed, and Interval, which would represent a signed quantity > > of a generic unit (ie: 10 minutes or 2 hours or 1 week or 5 years), or > > possibly a combination. Math would look like this: > > > > Interval + Interval => Interval > > Interval - Interval => Inverval > > DateTime + Interval => DateTime > > DateTime - Interval => DateTime > > DateTime - DateTime => Interval > > > > Since we're talking about databases, the types should try to stick fairly > > close to SQL, and SQL/92 already has provisions for DateTimes and > > Intervals. > > What is the rational for using a dedicated Interval class rather than > just > using numbers with agreed units. (See my other note?) Is the benefit > worth the added class? I'd vote for Interval class, as the convenient unit depends on the application domain. I can easily imagine applications where even subsecond intervals are interesting, as well as those where a day is a small unit. Harri ================= 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 Oct 30 14:26:14 1996 From: jim.fulton@digicool.com (Jim Fulton) Date: Wed, 30 Oct 1996 09:26:14 -0500 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) References: <3277549C.F10@digicool.com> <9610301335.AA05042@tahma.tekla.fi> Message-ID: <32776586.36C4@digicool.com> Harri Pasanen wrote: > > Jim Fulton writes: > > W. Craig Trader wrote: > > > > > > > arithmetic - difference between two dates. adding dates - it should be > > > > possible to produce a DateTime object representing "1 week" > > > > and say DateTime(now) + DateTime("1 week"). > > > > > > I think you're wrong here - there should be multiple types: DateTime, as > > > already discussed, and Interval, which would represent a signed quantity > > > of a generic unit (ie: 10 minutes or 2 hours or 1 week or 5 years), or > > > possibly a combination. Math would look like this: > > > > > > Interval + Interval => Interval > > > Interval - Interval => Inverval > > > DateTime + Interval => DateTime > > > DateTime - Interval => DateTime > > > DateTime - DateTime => Interval > > > > > > Since we're talking about databases, the types should try to stick fairly > > > close to SQL, and SQL/92 already has provisions for DateTimes and > > > Intervals. > > > > What is the rational for using a dedicated Interval class rather than > > just > > using numbers with agreed units. (See my other note?) Is the benefit > > worth the added class? > > I'd vote for Interval class, as the convenient unit depends on the > application domain. I can easily imagine applications where even > subsecond intervals are interesting, as well as those where a day is a > small unit. Even if the DateTime class exported unit conversion attributes? If I want to work in, say milliseconds, I can easily do: spam=(date1-date2)/DateTime.lengthOfSecond * 1000 without introducing a separate Interval class. Isn't this enough? If not, then how would an Interval class be used to solve this problem, and why would it be better? Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.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 mclay@nist.gov Wed Oct 30 14:49:12 1996 From: mclay@nist.gov (Michael McLay) Date: Wed, 30 Oct 1996 09:49:12 -0500 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: <9610301123.AA19322@kitty.tekla.fi> References: <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> <32768785.7F51@digicool.com> <9610301123.AA19322@kitty.tekla.fi> Message-ID: <199610301449.JAA30852@fermi.eeel.nist.gov> Petri Raitio writes: > Jim> If all three components are numbers that are less than 13, then > Jim> a a month-day-year ordering is assumed. > > I'd like to have less chance for misunderstanding here. I think there > should be a default format with a *fixed* DMY order, so that I could > tell the user that 10.30.1996 is not a valid (European) date. > > I wonder if it would make sense to use the separator as a format > specifier and have format-specific DMY orders, so that 10/30/1996 and > 30.10.1996 would be valid dates but 30/10/1996 and 10.30.1996 would > not. This way, it would be easy for us Europeans to specify a native > format date in a program written in the US. The ambiguity of DMY or MDY notation can be avoided by using 1996/10/30 instead of DMY or MDY notation. Standardizing on this also has the side effect of making string sorts of dates be chronologically ordered. This date ordering is the recommended practice for U.S. government agencies[1]. > Jim> Two-digit years are assumed to be in the twentieth century. > > This definition will become obsolete in a few years! Did you mean in > the *current* century? Using two-digit numbers for representing years is an avoidable source for errors in coding. Not allowing years to be less than 4 digits in the new date module would make Python "Year 2000" safe. That would be a good attribute to put in Python's feature list considering the growing concern over the problems that are anticipated on Jan 1, 1999. Time is independent of the calendars we use so an internal representation only needs to count units of time and establish what point in time the Epoch, time=0, represents. The POSIX standard arbitrarily assigns the date January 1, 1970 in Coordinate Universal Time. All local time calculations, such as leap seconds and daylight saving rules, are then simply offsets from the Epoch. The local offsets are arbitrarily set by local laws. Since these local laws are subject to change the core date module should avoid integrating them into a standard Python module. Perhaps the setting of the local time offset should be added as a feature of the new site.py module. If signed long integers are used to represent time then running out of digits is no longer a problem. This would allow the time increment to be lowered to microseconds, which would be helpful for some scientific calculations. Since computer speeds continue to increase this may also be helpful in operating system level functions as well. From a performance angle it might be better to use 64 bit integers for the representation internally. A 64 bit signed integer with microsecond resolution would provide at least 10k years of trouble free programming. (10k years is my cutoff on worrying about future problems:-) Of course this might cause problems if someone is doing calculations that date back to the origins of the universe, or when we can expect the national debt to be paid. [1] "REPRESENTATION FOR CALENDAR DATE AND ORDINAL DATE FOR INFORMATION INTERCHANGE" at http://www.nist.gov/itl/div897/pubs/fip4-1.htm FIPS 4 was originally issued in 1961. The original version allowed for an optional two-digit representation for year. This was recently changed to require the year to be represented as four digits. ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From per@tekla.fi Wed Oct 30 15:04:04 1996 From: per@tekla.fi (Petri Raitio) Date: Wed, 30 Oct 1996 17:04:04 +0200 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: <3277570B.4BD6@digicool.com> References: <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> <32768785.7F51@digicool.com> <9610301123.AA19322@kitty.tekla.fi> <3277570B.4BD6@digicool.com> Message-ID: <9610301504.AA26526@kitty.tekla.fi> "Jim" =3D=3D Jim Fulton writes: >> I'd like to have less chance for misunderstanding here. I think the= re >> should be a default format with a *fixed* DMY order, so that I could= >> tell the user that 10.30.1996 is not a valid (European) date. Jim> I think that this should be an option. That is, the programmer Jim> should have a flag, or perhaps a subclass, that enforces rules Jim> like you just mentioned. Ok, this is fine with me! >> I wonder if it would make sense to use the separator as a format >> specifier and have format-specific DMY orders, so that 10/30/1996 an= d >> 30.10.1996 would be valid dates but 30/10/1996 and 10.30.1996 would >> not. This way, it would be easy for us Europeans to specify a nativ= e >> format date in a program written in the US. Jim> This is an interesting idea. Is the correlation between Jim> delimiter and order really that strong? I don't know if it really is! In Finland it sure is, we all write 30.10.1996. Still, this is a bad idea if there is no wide-spread agreement on correlation. = Jim> Does anyone (in this discussion) know the rules for leap seconds? = = I would guess there are no rules, and these seconds are just randomly inserted here and there in some 'official' time; most of the world just doesn't give a damn. But maybe the code could be prepared if the C library returns funny values some day. = Jim> Two-digit years are assumed to be in the twentieth century. >> This definition will become obsolete in a few years! Did you mean >> in the *current* century? Jim> Actually, the "current" century definition would be very Jim> dangerous. There are alot of data sets that use 2-digit years Jim> and all of these would break on Jan 1, 2000 if a "current" Jim> century definition was used. I think the real problem is if you store dates with two-digit years, not if you input or output them with some convention for guessing the first two digits. = Jim> I've done day-of-week in the past. Week number is an interesting Jim> idea, but it sounds like it lacks a universal definition. I hate week numbers, but they are a common way of assigning approximate dates here, so I'll have to deal with them somehow.. Jim> Note that the DateTime class (whether implemented in C or Python) Jim> will be subclassable so perhaps features like "week number" Jim> should be defered to subclasses. =2E. and here's a great solution! Let's just forget about week numbers= for now. ================= 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 Oct 30 15:06:44 1996 From: jim.fulton@digicool.com (Jim Fulton) Date: Wed, 30 Oct 1996 10:06:44 -0500 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) References: <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> <32768785.7F51@digicool.com> <9610301123.AA19322@kitty.tekla.fi> <199610301449.JAA30852@fermi.eeel.nist.gov> Message-ID: <32776F04.29AE@digicool.com> Michael McLay wrote: > > Petri Raitio writes: > > Jim> If all three components are numbers that are less than 13, then > > Jim> a a month-day-year ordering is assumed. > > > > I'd like to have less chance for misunderstanding here. I think there > > should be a default format with a *fixed* DMY order, so that I could > > tell the user that 10.30.1996 is not a valid (European) date. > > > > I wonder if it would make sense to use the separator as a format > > specifier and have format-specific DMY orders, so that 10/30/1996 and > > 30.10.1996 would be valid dates but 30/10/1996 and 10.30.1996 would > > not. This way, it would be easy for us Europeans to specify a native > > format date in a program written in the US. > > The ambiguity of DMY or MDY notation can be avoided by using > 1996/10/30 instead of DMY or MDY notation. This limits the usefulness of the default format. > Standardizing on this also > has the side effect of making string sorts of dates be chronologically > ordered. Not if dates include local time information with time zone labels. > This date ordering is the recommended practice for > U.S. government agencies[1]. Sound's like a good reason to avoid this ordering. ;-) > > Jim> Two-digit years are assumed to be in the twentieth century. > > > > This definition will become obsolete in a few years! Did you mean in > > the *current* century? > > Using two-digit numbers for representing years is an avoidable source > for errors in coding. Not allowing years to be less than 4 digits in > the new date module would make Python "Year 2000" safe. That would be > a good attribute to put in Python's feature list considering the > growing concern over the problems that are anticipated on Jan 1, 1999. Saying that 2-digit years refer to the 20th century, rather than the "current" century is also "Year 2000" safe. > Time is independent of the calendars we use so an internal > representation only needs to count units of time and establish what > point in time the Epoch, time=0, represents. The POSIX standard > arbitrarily assigns the date January 1, 1970 in Coordinate > Universal Time. All local time calculations, such as leap seconds and > daylight saving rules, are then simply offsets from the Epoch. The > local offsets are arbitrarily set by local laws. Since these local > laws are subject to change the core date module should avoid > integrating them into a standard Python module. Perhaps the setting > of the local time offset should be added as a feature of the new > site.py module. > > If signed long integers are used to represent time then running out of > digits is no longer a problem. This would allow the time increment to > be lowered to microseconds, which would be helpful for some scientific > calculations. Since computer speeds continue to increase this may > also be helpful in operating system level functions as well. From a > performance angle it might be better to use 64 bit integers for the > representation internally. A 64 bit signed integer with microsecond > resolution would provide at least 10k years of trouble free > programming. (10k years is my cutoff on worrying about future > problems:-) Of course this might cause problems if someone is doing > calculations that date back to the origins of the universe, or when we > can expect the national debt to be paid. I'm growing more and more inclined to specify a Python date-time interface that leaves implementation issues like these open. > [1] "REPRESENTATION FOR CALENDAR DATE AND ORDINAL DATE FOR > INFORMATION INTERCHANGE" at http://www.nist.gov/itl/div897/pubs/fip4-1.htm > FIPS 4 was originally issued in 1961. The original version allowed > for an optional two-digit representation for year. This was recently > changed to require the year to be represented as four digits. I'll look at this. Thanks. Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.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 dan@digicool.com Wed Oct 30 18:56:56 1996 From: dan@digicool.com (Dan Manganelli) Date: Wed, 30 Oct 1996 12:56:56 -0600 Subject: [PYTHON DB-SIG] Re:oracledb module available Message-ID: <3277A4F8.7493@digicool.com> We have a newer version of the oracledb module available. Many thanks to Anthony Baxter for helping us with the new version. You can get it at: ftp://ftp.digicool.com/pub/releases/oracledb-0.1.1/oracledb-0.1.1.tar.gz -- ##################################################### # Daniel F Manganelli || email : dan@digicool.com # # Software Engineer || Digital Creations # ##################################################### ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From pa@tekla.fi Wed Oct 30 21:12:03 1996 From: pa@tekla.fi (Harri Pasanen) Date: Wed, 30 Oct 1996 23:12:03 +0200 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: <32776586.36C4@digicool.com> References: <3277549C.F10@digicool.com> <9610301335.AA05042@tahma.tekla.fi> <32776586.36C4@digicool.com> Message-ID: <9610302112.AA09173@tahma.tekla.fi> Jim Fulton writes: > Harri Pasanen wrote: > > > > > > What is the rational for using a dedicated Interval class rather than > > > just > > > using numbers with agreed units. (See my other note?) Is the benefit > > > worth the added class? > > > > I'd vote for Interval class, as the convenient unit depends on the > > application domain. I can easily imagine applications where even > > subsecond intervals are interesting, as well as those where a day is a > > small unit. > > Even if the DateTime class exported unit conversion attributes? > If I want to work in, say milliseconds, I can easily do: > > spam=(date1-date2)/DateTime.lengthOfSecond * 1000 > > without introducing a separate Interval class. Isn't this enough? > If not, then how would an Interval class be used to solve this problem, > and why would it be better? > I reread your previous note (somehow I missed the conversion attribute suggestion), and agree that this would be a workable solution. With my idea of an Interval class, the above would look like something like spam = Interval(date1-date2).milliSeconds() But I'd probably have to elaborate the Interval class a bit further to see if I'm making sense to myself, and probably would have to do a prototype implementation. Somehow just working with the concept of DateTimes, which are points in the linear time vector, and Intervals, which are line segments on the same time vector, seems very intuitive to me. That said, I won't have time do actual implementation in near future, so I accept with gratitude any implementation. Harri ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From Anthony Baxter Wed Oct 30 23:02:36 1996 From: Anthony Baxter (Anthony Baxter) Date: Thu, 31 Oct 1996 10:02:36 +1100 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: Your message of "Wed, 30 Oct 1996 08:09:05 CDT." <32775371.35AE@digicool.com> References: <32775371.35AE@digicool.com> <32768785.7F51@digicool.com> <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> <199610300110.MAA04639@jambu.off.connect.com.au> Message-ID: <199610302302.KAA07340@jambu.off.connect.com.au> >>> Jim Fulton wrote > Oops. In my earlier note I agreed with this without reading it > carefully enough. DateTime("1 week") doesn't make any sense to me. > DateTime objects refer to specific points in time, not time units. Yep, so we need something else, instead... > I think that DateTime objects should support addition/subtraction of > numbers to/from date-time objects. I think we should decide what units > are used for this. IMO the units should be either days or seconds. > I'd vote for days myself, but I could live with seconds. I'd say that "DateTime(now) + 3" should be an error. Either specify the units you're talking about, or lose to ambiguity. What's a reasonable default for you is not going to be reasonable for the next person along. And in this case, a settable default would make code yucky to read. > In addition, the DateTime class should have attributes that give the > lengths of various units of time. Perhaps these attributes should be: > lengthOfYear(year), lengthOfMonth(year,month), lengthOfWeek, > lengthOfDay, lengthOfHour, lengthOfMinute, lengthOfSecond. So the above > expression would become: > DateTime(now) + DateTime.lengthOfWeek That's ok for addition and subtraction of an interval to a date, but what should 'DateTime(now) - DateTime("03 Mar 1996 13:45:23")' return? The only options I can see are: return an int, of some fixed type (seconds difference? what happens if they want milliseconds?) return some new type, which can be queried for seconds, hours, days, whatever. Anthony ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From Anthony Baxter Wed Oct 30 23:10:38 1996 From: Anthony Baxter (Anthony Baxter) Date: Thu, 31 Oct 1996 10:10:38 +1100 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: Your message of "Wed, 30 Oct 1996 08:24:27 CDT." <3277570B.4BD6@digicool.com> References: <3277570B.4BD6@digicool.com> <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> <32768785.7F51@digicool.com> <9610301123.AA19322@kitty.tekla.fi> Message-ID: <199610302310.KAA07376@jambu.off.connect.com.au> >>> Jim Fulton wrote > Petri Raitio wrote: > > I wonder if it would make sense to use the separator as a format > > specifier and have format-specific DMY orders, so that 10/30/1996 and > > 30.10.1996 would be valid dates but 30/10/1996 and 10.30.1996 would > > not. This way, it would be easy for us Europeans to specify a native > > format date in a program written in the US. > > This is an interesting idea. Is the correlation between delimiter and > order really that strong? I doubt it. Australia uses D/M/Y, and, f'r instance, every piece of paper I've seen from a bank has a field like __ / __ / ____ and expects day, month, year. (actually, they usually have it like __ / __ / 19__, but that's just banks being morons.) > Does anyone (in this discussion) know the rules for leap seconds? I've fired off some mail to some people I know who may be able to help. > > This definition will become obsolete in a few years! Did you mean in > > the *current* century? > Actually, the "current" century definition would be very dangerous. > There are alot of data sets that use 2-digit years and all of these would > break on Jan 1, 2000 if a "current" century definition was used. How about we compromise - a 2 digit year will refer to the _closest_ year with the last two digits. (96 = 1996, 02 = 2002, 85 = 1985...) > > Fine, this is absolutely required! Note, that the system locale is > > not very useful, so the strings need to come from the module that uses > > the Date module. (I don't want my 'ls' to tell me a file is dated > > '30 Loka' when it is really 'Oct 30'.) Make a DateI18N module to hold all this sort of stuff. Anthony ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From Anthony Baxter Wed Oct 30 23:46:27 1996 From: Anthony Baxter (Anthony Baxter) Date: Thu, 31 Oct 1996 10:46:27 +1100 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: Your message of "Wed, 30 Oct 1996 09:49:12 CDT." <199610301449.JAA30852@fermi.eeel.nist.gov> References: <199610301449.JAA30852@fermi.eeel.nist.gov> <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> <32768785.7F51@digicool.com> <9610301123.AA19322@kitty.tekla.fi> Message-ID: <199610302346.KAA07473@jambu.off.connect.com.au> >>> Michael McLay wrote > The ambiguity of DMY or MDY notation can be avoided by using > 1996/10/30 instead of DMY or MDY notation. Standardizing on this also > has the side effect of making string sorts of dates be chronologically > ordered. This date ordering is the recommended practice for > U.S. government agencies[1]. But this also reduces the usefulness of the DateTime class - we should be able to parse dates, as returned by various systems, and produce something useful out the other side. Insisting that the input is always in a particular format breaks this. For example, _right_now_ I have systems that have to parse dates that are in the following formats. (bonus points to anyone who can identify where these are all from :) Thu Oct 31 10:32:20 EST 1996 23:08:50 UTC Sat Oct 19 1996 Oct 27 04:01:17 Fri, 27 Sep 1996 10:25:23 +1000 Thu Oct 31 10:36 EST 1996 28 Oct 96 23:34:02 GMT > Using two-digit numbers for representing years is an avoidable source > for errors in coding. Not allowing years to be less than 4 digits in > the new date module would make Python "Year 2000" safe. That would be > a good attribute to put in Python's feature list considering the > growing concern over the problems that are anticipated on Jan 1, 1999. Again, an awful lot of stuff out there produces dates with 2 digit years. The suggestion I made earlier (make it handle 2 digit years by picking the closest one to 'now') would seem to handle this reasonably well - assuming that the only two digit years out there are produced by other computer systems, so you're not likely to get something outputting '11/11/18' meaning 11 Nov 1918, but you are likely to get something outputting '23 Oct 93' meaning 1993. Yes, it would be nice if everything used 4 digit years, and all new systems should _only_ output 4 digit years[*], but I don't see a problem with being able to parse 2 digit years as input. [*] I'd suggest that the formatted output method of the datetime class not have a code for two digit year. If they really want a two digit year, make em work for it :) > All local time calculations, such as leap seconds and > daylight saving rules, are then simply offsets from the Epoch. The > local offsets are arbitrarily set by local laws. Since these local > laws are subject to change the core date module should avoid > integrating them into a standard Python module. Perhaps the setting > of the local time offset should be added as a feature of the new > site.py module. Hardcoding the TZ is not good enough. 'site.py' is for a python installation, not for a site. eg, koro.off.connect.com.au:/opt/python/lib/python1.4/site.py is used by computer systems in 7 different timezones. I like Jim's idea of making timezone handling a seperate module - systems that support timezones reasonably can deal with them, then. Anthony ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From tmb@best.com Thu Oct 31 01:18:32 1996 From: tmb@best.com (Thomas Breuel) Date: Wed, 30 Oct 1996 17:18:32 -0800 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) References: <3277570B.4BD6@digicool.com> <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> <32768785.7F51@digicool.com> <9610301123.AA19322@kitty.tekla.fi> Message-ID: <199610310118.RAA23123@shellx.best.com> >>> Jim Fulton wrote > Petri Raitio wrote: > > I wonder if it would make sense to use the separator as a format > > specifier and have format-specific DMY orders, so that 10/30/1996 and > > 30.10.1996 would be valid dates but 30/10/1996 and 10.30.1996 would > > not. This way, it would be easy for us Europeans to specify a native > > format date in a program written in the US. > > This is an interesting idea. Is the correlation between delimiter and > order really that strong? I doubt it. Australia uses D/M/Y, and, f'r instance, every piece of paper I've seen from a bank has a field like __ / __ / ____ and expects day, month, year. (actually, they usually have it like __ / __ / 19__, but that's just banks being morons.) In the US, "/" pretty strongly suggest "month/day" order, while other delimiters ("-", ".") pretty strongly suggest "day-month" order (the year is unambiguous right now, either because it's 4 digits, or because it's too large to be a day or month). In fact, if an Australian uses "/" in dates in business correspondence with the US, they will be misunderstood. Complete lack of a delimiter (19961031) strongly suggests YMD order. Of course, the least ambiguous way of writing dates is using three letter abbreviations for the month and four digit years (10 Jan 1996). I believe that, at least for the most common languages using Roman script, the months are unambiguous even if you don't know the language that the date was written in. Thomas. ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From Anthony Baxter Thu Oct 31 01:49:53 1996 From: Anthony Baxter (Anthony Baxter) Date: Thu, 31 Oct 1996 12:49:53 +1100 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: Your message of "Wed, 30 Oct 1996 17:18:32 -0800." <199610310118.RAA23123@shellx.best.com> References: <199610310118.RAA23123@shellx.best.com> <3277570B.4BD6@digicool.com> <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> <32768785.7F51@digicool.com> <9610301123.AA19322@kitty.tekla.fi> Message-ID: <199610310149.MAA08105@jambu.off.connect.com.au> >>> Thomas Breuel wrote > In the US, "/" pretty strongly suggest "month/day" order, while other > delimiters ("-", ".") pretty strongly suggest "day-month" order (the > year is unambiguous right now, either because it's 4 digits, or because > it's too large to be a day or month). In fact, if an Australian uses > "/" in dates in business correspondence with the US, they will be > misunderstood. Complete lack of a delimiter (19961031) strongly > suggests YMD order. Sure, but we're talking about parsing dates in general. In a perfect world we'd all just use YYYYMMDD and not have to worry about this. Ever tried filling out a piece of paper for a non computer person with a date of 19961031? They get upset. Hardcoding a parser to assume that the use of / as a delimeter means "US M/D/Y" format would be very suboptimal. I can't see any alternative apart from making it a switch as to which format you want. > Of course, the least ambiguous way of writing dates is using three > letter abbreviations for the month and four digit years (10 Jan 1996). > I believe that, at least for the most common languages using Roman > script, the months are unambiguous even if you don't know the language > that the date was written in. Sure, and when building systems this is something everyone should do. I'm talking about parsing dates, generated by something that's not necessarily within the control of the programmer. Anthony ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From gstein@microsoft.com Thu Oct 31 06:34:28 1996 From: gstein@microsoft.com (Greg Stein) Date: Wed, 30 Oct 1996 22:34:28 -0800 Subject: [PYTHON DB-SIG] RE: Date-Time requirements (esp. for databases) Message-ID: >---------- >From: Anthony Baxter[SMTP:arb@connect.com.au] >Sent: Wednesday, October 30, 1996 5:49 PM >To: Thomas Breuel >Cc: db-sig@python.org >Subject: Re: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. >for databases) > >Hardcoding a parser to assume that the use of / as a delimeter means >"US M/D/Y" format would be very suboptimal. I can't see any alternative >apart from making it a switch as to which format you want. You need to be *very* careful with "switches." What if my module wants M/D/Y and yours wants D/M/Y, so we set the flag in the date module? Oops. One of our modules won't work. Again, I'll reiterate: I believe that the C module only implement the core date-time Type and we punt formatting and parsing up to Python. Why? Heck... just look at the darn discussion... this amount of discussion means that the problem is inherently difficult, prone to subjective viewpoints and needs, unknown requirements, etc. Creating a requirements or specification for formatting/parsing is just fooling yourself into thinking that you got them all. -g >-- >Greg Stein, Microsoft Corporation execfile("disclaimer.py") ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From fredrik_lundh@ivab.se Thu Oct 31 08:30:51 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Thu, 31 Oct 1996 09:30:51 +0100 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: <199610301449.JAA30852@fermi.eeel.nist.gov> (message from Michael McLay on Wed, 30 Oct 1996 09:49:12 -0500) Message-ID: <9610310830.AA01126@arnold.image.ivab.se> > This date ordering is the recommended practice for U.S. government > agencies[1]. Related to the international standard, I suppose. Here's some background info I found on the web a few month ago, including a pointer to more stuff. Share and enjoy (FWIW, Sweden adopted ISO 8601 back in the seventies). /F -------------------------------------------------------------------- Date: Mon Jul 12 17:00:39 1996 Author: Fredrik Lundh Subject: International Standard Date and Time Notation A Summary of the International Standard Date and Time Notation International Standard ISO 8601 specifies numeric representations of date and time. This standard notation helps to avoid confusion in international communication caused by the many different national notations and increases the portability of computer user interfaces. In addition, these formats have several important advantages for computer usage compared to other traditional date and time notations. The time notation described here is already the de-facto standard in almost all countries and the date notation is becoming increasingly popular. Especially software engineers who design user interfaces, file formats, and communication protocols should be familiar with ISO 8601. Contents: Date, Time of Day, Time Zone. Date The international standard date notation is YYYY-MM-DD where YYYY is the year in the usual Gregorian calendar, MM is the month of the year between 01 (January) and 12 (December), and DD is the day of the month between 01 and 31. For example, the fourth day of February in the year 1995 is written in the standard notation as 1995-02-04 Other commonly used notations are e.g. 2/4/95, 4/2/95, 95/2/4, 4.2.1995, 04-FEB-1995, 4-February-1995, and many more. Especially the first two examples are dangerous, because as both are used quite often in the USA and in Great Britain and both can not be distinguished, it is unclear whether 2/4/95 means 1995-04-02 or 1995-02-04. The date notation 2/4/5 has at least six reasonable interpretations (assuming that only the twentieth and twenty-first century are reasonable candidates in our live time). Advantages of the ISO 8601 standard date notation compared to other commonly used variants: * easily readable and writeable by software (no 'JAN', 'FEB', ... table necessary) * easily comparable and sortable with a trivial string comparison * language independent * can not be confused with other popular date notations * consistency with the common 24h time notation system, where the larger units (hours) are also written in front of the smaller ones (minutes and seconds) * strings containing a date followed by a time are also easily comparable and sortable (e.g. write "1995-02-04 22:45:00") * the notation is short and has constant length, which makes both keyboard data entry and table layout easier * identical to the Chinese date notation, so the largest cultural group (>25%) on this planet is already familiar with it :-) * date notations with the order "year, month, day" are in addition already widely used e.g. in Japan, Korea, Hungary, Sweden, Finland, Denmark, and a few other countries and people in the US are already used to at least the "month, day" order * a 4-digit year representation avoids overflow problems after 1999-12-31 As dates will look a little bit strange anyway starting with 2000-01-01 (e.g. like 1/1/0), it has been suggested that the year 2000 is an excellent opportunity to change to the standard date notation. Apart from the recommended primary standard notation YYYY-MM-DD, ISO 8601 also specifies a number of alternative formats for use in applications with special requirements. All of these alternatives can easily and automatically be distinguished from each other: The hyphens can be omitted if compactness of the representation is more important than human readability, for example as in 19950204 For situations where information about the century is really not required, a 2-digit year representation is available: 95-02-04 or 950204 If only the month or even only the year is of interest: 1995-02 or 1995 In commercial and industrial applications (delivery times, production plans, etc.), especially in Europe, it is often required to refer to a week of a year. Week 01 of a year is per definition the first week that has the Thursday in this year, which is equivalent to the week that contains the fourth day of January. In other words, the first week of a new year is the week that has the majority of its days in the new year. Week 01 might also contain days from the previous year and the week before week 01 of a year is the last week (52 or 53) of the previous year even if it contains days from the new year. A week starts with Monday (day 1) and ends with Sunday (day 7). For example, the first week of the year 1997 lasts from 1996-12-30 to 1997-01-05 and can be written in standard notation as 1997-W01 or 1997W01 The week notation can also be extended by a number indicating the day of the week. For example, the day 1996-12-31, which is the Tuesday (day 2) of the first week of 1997, can also be written as 1997-W01-2 or 1997W012 for applications like industrial planning where many things like shift rotations are organized per week and knowing the week number and the day of the week is more handy than knowing the day of the month. An abbreviated version of the year and week number like 95W05 is sometimes useful as a compact code printed on a product that indicates when it has been manufactured. The ISO standard avoids explicitly stating the possible range of week numbers, but this can easily be deduced from the definition: Theorem: Possible ISO week numbers are in the range 01 to 53. A year always has a week 52. (There is one historic exception: the year in which the Gregorian calendar was introduced had less than 365 days and less than 52 weeks.) Proof: Per definition, the first week of a year is W01 and consequently days before week W01 belong to the previous year and so there is no week with lower numbers. Considering the highest possible week number, the worst case is a leap year like 1976 that starts with a Thursday, because this keeps the highest possible number of days of W01 in the previous year, i.e. 3 days. In this case, the Sunday of W52 of the worst case year is day number 4+51*7=361 and 361-366=5 days of W53 belong still to this year, which guarantees that in the worst case year day 4 (Thursday) of W53 is not yet in the next year, so a week number 53 is possible. For example, the 53 weeks of the worst case year 1976 started with 1975-12-29 = 1976-W01-1 and ended with 1977-01-02 = 1976-W53-7. On the other hand, considering the lowest number of the last week of a year, the worst case is a non-leap year like 1999 that starts with a Friday, which ensures that the first three days of the year belong to the last week of the previous year. In this case, the Sunday of week 52 would be day number 3+52*7=367, i.e. only the last 367-365=2 days of the W52 reach into the next year and consequently, even a worst case year like 1999 has a week W52 including the days 1999-12-27 to 2000-01-02. q.e.d. [Unfortunately, the current version of the C programming language standard provides in the strftime() function no means to generate the ISO 8601 week notation. A required extension would be four new formatting codes: for the year of the week to which the specified day belongs (both 2-digit and 4-digit), for the number of the week between 01 and 53, and for the day of the week between 1 (Monday) and 7 (Sunday). Another trivial mistake in the description of strftime() in the C standard is that the range of seconds goes from 00 to 61, because at one time only one single leap second 60 can be inserted into UTC and consequently there will never be a leap second 61.] Both day and year are useful units of structuring time, because the position of the sun on the sky, which influences our lives, is described by them. However the 12 months of a year are of some obscure mystic origin and have no real purpose today except that people are used to having them (they do not even describe the current position of the moon). In some applications, a date notation is preferred that uses only the year and the day of the year between 001 and 365 (366 in leap years). The standard notation for this variant representing the day 1995-02-04 (that is day 035 of the year 1995) is 1995-035 or 1995035 Leap years are years with an additional day YYYY-02-29, where the year number is a multiple of four with the following exception: If a year is a multiple of 100, then it is only a leap year if it is also a multiple of 400. For example, 1900 was not a leap year, but 2000 is one. Time of Day The international standard notation for the time of day is hh:mm:ss where hh is the number of complete hours that have passed since midnight (00-24), mm is the number of complete minutes that have passed since the start of the hour (00-59), and ss is the number of seconds since the start of the minute (00-60). The value 60 for ss appears only in case of an inserted leap second into an atomic time scale like UTC in order to keep it synchronized with a less constant astronomical time scale like UT1. The hour value 24 is only possible when the minute and second values are zero. An example time is 23:59:59 which represents the time one second before midnight. As with the date notation, the separating colons can also be omitted as in 235959 and the precision can be reduced by omitting the seconds or both the seconds and minutes as in 23:59, 2359, or 23 It is also possible to add fractions of a second after a decimal dot, e.g. the time 5.8 ms before midnight can be written as 23:59:59.9942 or 235959.9942 As every day both starts and ends with midnight, the two notations 00:00 and 24:00 are available to distinguish the two midnights that can be associated with one date. This means that the following two strings refer to exactly the same point in time: 1995-02-04 24:00 = 1995-02-05 00:00 In case an unambiguous representation of time is required, 00:00 is usually the preferred notation for midnight, which is also what most digital clocks display. A remark for readers from the US: The 24h time notation specified here has already been the de-facto standard all over the world in written language for decades. The only exception are some English speaking countries, where still notations with hours between 1 and 12 and additions like "a.m." and "p.m." are in wide use. The common 24h international standard notation starts to get widely used now even in England. Other languages than English don't even have abbreviations like "a.m." and "p.m." and the 12h notation is certainly hardly ever used on Continental Europe to write or display a time. The old English 12h notation has many disadvantages like: * It is not clear, how 00:00, 12:00 and 24:00 are represented (even encyclopedias and style manuals contain contradicting descriptions and a common quick fix seems to be to avoid "12:00 a.m./p.m." altogether and write "noon", "midnight" or "12:01 a.m./p.m." instead). * It makes people often believe that the next day starts at the overflow from "12:59 a.m." to "1:00 a.m.", which is a common problem not only when people try to program the timer of VCRs shortly after midnight. * It is not easily comparable with a string compare operation. * It is not immediately clear for the unaware, whether the time between "12:00 a.m./p.m." and "1:00 a.m./p.m." starts at 00:00 or at 12:00, i.e. the English 12h notation is more difficult to understand. * It is longer than the normal 24h notation. The 12h time is simply a relic from the dark ages when Roman numerals were used, the number zero had not yet been invented and analog clocks where the only known form of displaying a time. Please avoid using it today, especially in technical applications! Even in the US, the widely respected Chicago Manual of Style recommends now to use the international standard time notation in publications. Time Zone Without any further additions, a date and time as written above is assumed to be in some local time zone. In order to indicate that a time is measured in Universal Time (UTC), you can append a capital letter Z to a time as in 23:59:59Z or 2359Z [The Z stands for the "zero meridian", which goes through Greenwich in London, and it is also commonly used in radio communication where it is pronounced "Zulu" (the word for Z in the NATO radio alphabet). Universal Time (sometimes also called "Zulu Time") was called Greenwich Mean Time (GMT) before 1972, however this term should no longer be used. Since the introduction of an international atomic time scale, almost all existing civil time zones are now related to UTC, which is slightly different from the old and now unused GMT.] The strings +hh:mm, +hhmm, or +hh can be added to the time to indicate that the used local time zone is hh hours and mm minutes ahead of UTC. For time zones west of the zero meridian, which are behind UTC, the notation -hh:mm, -hhmm, or -hh is used instead. For example, Middle European Time (MET) is +0100 and US/Canadian Eastern Standard Time (EST) is -0500. The following strings all indicate the same point of time: 12:00Z = 13:00+01:00 = 0700-0500 There exists no international standard that specifies abbreviations for civil time zones like MET, EST, etc. and sometimes the same abbreviation is even used for two very different time zones. In addition, politicians enjoy modifying the rules for civil time zones, especially for daylight saving times, every few years, so the only really reliable way of describing a local time zone is to specify numerically the difference of local time to UTC. Better use directly UTC as your only time zone where this is possible and then you do not have to worry about time zones and daylight saving time changes at all. For those readers interested in more information about time zones: Arthur David Olson maintains a database of all current and many historic time zone changes. It is available via ftp from elsie.nci.nih.gov in the tzcode* and tzdata* files. Most Unix time zone handling implementations are based on this package. If you want to join the tz@elsie.nci.nih.gov mailing list, which is dedicated to discussions about time zones, please send a short message to tz-request@elsie.nci.nih.gov. ---------------------------------------------------------------------------- This was a brief overview of the ISO 8601 standard, which covers only the most useful notations and includes some additional related information. The full standard defines in addition a number of more exotic notations including some for periods of time. The ISO 8601 document is unfortunately not available online and interested people will have to order a paper copy from International Organization for Standardization Case postale 56 1, rue de Varembi CH-1211 Genhve 20 Switzerland phone: +41 22 749 01 11 fax: +41 22 733 34 30 e-mail: sales@isocs.iso.ch A more detailed online summary of ISO 8601 than this one is the text ISO 8601:1988 Date/Time Representations available from ftp.informatik.uni-erlangen.de/pub/doc/ISO/ISO8601.ps.Z (PostScript, 16 kb, 5 pages) written by Gary Houston, which is now also available in HTML. ---------------------------------------------------------------------------- I wish to thank Edward M. Reingold for developing the fine GNU Emacs calendar functions, as well as Rich Wales, Mark Brader, Paul Eggert, and others in the comp.std.internat, comp.protocols.time.ntp, and sci.astro USENET discussion groups for valuable comments about this text. Further comments and hyperlinks to this page are very welcome. Markus Kuhn , 1996-05-14 -------------------------------------------------------------------- ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From per@tekla.fi Thu Oct 31 09:15:10 1996 From: per@tekla.fi (Petri Raitio) Date: Thu, 31 Oct 1996 11:15:10 +0200 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: <199610310118.RAA23123@shellx.best.com> References: <3277570B.4BD6@digicool.com> <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> <32768785.7F51@digicool.com> <9610301123.AA19322@kitty.tekla.fi> <199610310118.RAA23123@shellx.best.com> Message-ID: <9610310915.AA32329@kitty.tekla.fi> "Thomas" =3D=3D Thomas Breuel writes: Thomas> Of course, the least ambiguous way of writing dates is using Thomas> three letter abbreviations for the month and four digit years Thomas> (10 Jan 1996). I believe that, at least for the most common Thomas> languages using Roman script, the months are unambiguous even Thomas> if you don't know the language that the date was written in. This will not help everyone; tomorrow it is '1 Mar 1996' in Finland, for example. Also, the convention of using an abbreviated month name is not in use in several (if not most) European countries. Now I know most users of this new date module will speak English, but it would be great to have the module work with all kinds of languages with just minor subclassing, so I think I'll keep bothering you all with my requirements ;) ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From per@tekla.fi Thu Oct 31 09:40:45 1996 From: per@tekla.fi (Petri Raitio) Date: Thu, 31 Oct 1996 11:40:45 +0200 Subject: [PYTHON DB-SIG] RE: Date-Time requirements (esp. for databases) In-Reply-To: =?ISO-8859-1?Q??= References: =?ISO-8859-1?Q??= Message-ID: <9610310940.AA00727@kitty.tekla.fi> "Greg" =3D=3D Greg Stein writes: >> Hardcoding a parser to assume that the use of / as a delimeter means= >> "US M/D/Y" format would be very suboptimal. I can't see any alternat= ive >> apart from making it a switch as to which format you want. Greg> You need to be *very* careful with "switches." What if my module = wants Greg> M/D/Y and yours wants D/M/Y, so we set the flag in the date modul= e? Greg> Oops. One of our modules won't work. I think it's the *user* that wants to work with a certain format, and this switch should be set in the 'main' program, along with the language settings. Modules should use the explicit way, Date.Date(1996, 10, 31), or if strings are required, with an universally unambiguous format, which I would suggest be 1996-10-31. Also, Date.Date("10/31/1996", "%M/%D/%Y") always works, even for Date subclasses. Greg> Again, I'll reiterate: I believe that the C module only implement= the Greg> core date-time Type and we punt formatting and parsing up to Pyth= on. Greg> Why? Heck... just look at the darn discussion... this amount of Greg> discussion means that the problem is inherently difficult, prone = to Greg> subjective viewpoints and needs, unknown requirements, etc. Creat= ing a Greg> requirements or specification for formatting/parsing is just fool= ing Greg> yourself into thinking that you got them all. Just a moment! What I would like is that the rules would be spelled out, something like: * the standard date module contains a Date.Date class that supports certain common and useful date formats, such as 1996-10-31, 10/31/1996, the Unix date command output, and so on * the DMY order for Date.Date is fixed at M/D/Y, regardless of separator, so that there is no confusion with 5/5/5; four digits in the first position imply Y/M/D * I can subclass Date.Date, so that it speaks Finnish, defaults to D/M/Y, and whatever This way, programs written with Date without much thought for non-US date representations would always allow me to input a safe 1996-10-31, although I would get 10/31/1996 out. And I would still have all the flexibility I need! ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From per@tekla.fi Thu Oct 31 11:54:23 1996 From: per@tekla.fi (Petri Raitio) Date: Thu, 31 Oct 1996 13:54:23 +0200 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: <150992557479035482@toto.iv> References: <9610292109.AA24803@tahma.tekla.fi> Message-ID: <9610311154.AA03996@kitty.tekla.fi> "Petri" =3D=3D Petri Raitio writes: Petri> I would also like to see operations for inquiring week number Petri> and day-of-week information; I have a week number algorithm Petri> that returns correct week numbers according to the definition Petri> here in Finland, but I'm not sure how universal this is. Petri> (Weeks start with Monday; the first Friday in January is always Petri> on week 1; thus the week number can run up to 53, the last week Petri> in a year can be number 1 from the next year, and the first Petri> week can be 52 or 53 from the previous year.) I just read Fredrik's description of the ISO standard week numbers, which says that *Thursday* is the crucial day. This happens to be correct ;) My interpretation (Friday) was verified with the (Danish) Time System calendar, which tells me Friday, Jan 1, 1999 would be week 1, whereas is should really be week 53! I just called them, and they admitted there is an error in the calendar. ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From mclay@nist.gov Thu Oct 31 16:16:55 1996 From: mclay@nist.gov (Michael McLay) Date: Thu, 31 Oct 1996 11:16:55 -0500 Subject: [PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases) In-Reply-To: <199610302346.KAA07473@jambu.off.connect.com.au> References: <199610301449.JAA30852@fermi.eeel.nist.gov> <9610281750.AA00627@ninny.digicool.com> <32762B1C.3C17@digicool.com> <9610292109.AA24803@tahma.tekla.fi> <32768785.7F51@digicool.com> <9610301123.AA19322@kitty.tekla.fi> <199610302346.KAA07473@jambu.off.connect.com.au> Message-ID: <199610311616.LAA03727@fermi.eeel.nist.gov> Anthony Baxter writes: > > >>> Michael McLay wrote > > The ambiguity of DMY or MDY notation can be avoided by using > > 1996/10/30 instead of DMY or MDY notation. Standardizing on this also > > has the side effect of making string sorts of dates be chronologically > > ordered. This date ordering is the recommended practice for > > U.S. government agencies[1]. > > But this also reduces the usefulness of the DateTime class - we should be > able to parse dates, as returned by various systems, and produce something > useful out the other side. Insisting that the input is always in a particular > format breaks this. I'm not saying this shouldn't be supported. It just shouldn't be supported in the core module. Make the core module completely safe and then import that module into a module with lots of really useful and general purpose readers. (This extension should still only output in the standard format.) Then finally make a third module that imports the middle layer which includes general purpose output capabilities for everything from a Roman numeral syntax to a Chinese calendar. This approach allows code to be scanned for things that may be dangerous by looking for the layer 2 or layer 3 module names. Anything that uses layer one is presumed safe. > > For example, _right_now_ I have systems that have to parse dates that are > in the following formats. (bonus points to anyone who can identify where > these are all from :) > > Thu Oct 31 10:32:20 EST 1996 > 23:08:50 UTC Sat Oct 19 1996 > Oct 27 04:01:17 > Fri, 27 Sep 1996 10:25:23 +1000 > Thu Oct 31 10:36 EST 1996 > 28 Oct 96 23:34:02 GMT Layer 2 should be able to read each of these, but Layer 1 and layer 2 shoould be assumed safe for outputing in a standard notation. > > Using two-digit numbers for representing years is an avoidable source > > for errors in coding. Not allowing years to be less than 4 digits in > > the new date module would make Python "Year 2000" safe. That would be > > a good attribute to put in Python's feature list considering the > > growing concern over the problems that are anticipated on Jan 1, 1999. > > Again, an awful lot of stuff out there produces dates with 2 digit years. > The suggestion I made earlier (make it handle 2 digit years by picking the > closest one to 'now') would seem to handle this reasonably well - assuming > that the only two digit years out there are produced by other computer systems, > so you're not likely to get something outputting '11/11/18' meaning > 11 Nov 1918, but you are likely to get something outputting '23 Oct 93' > meaning 1993. Yes, it would be nice if everything used 4 digit years, and > all new systems should _only_ output 4 digit years[*], but I don't see a problem > with being able to parse 2 digit years as input. I agree you need to be able to read in the old formats, but keeping the modules for backward compatiblity separate allows the programs that are standard comformant to be more efficient and easier to test. > [*] I'd suggest that the formatted output method of the datetime class not > have a code for two digit year. If they really want a two digit year, make > em work for it :) > > > All local time calculations, such as leap seconds and > > daylight saving rules, are then simply offsets from the Epoch. The > > local offsets are arbitrarily set by local laws. Since these local > > laws are subject to change the core date module should avoid > > integrating them into a standard Python module. Perhaps the setting > > of the local time offset should be added as a feature of the new > > site.py module. > > Hardcoding the TZ is not good enough. 'site.py' is for a python installation, > not for a site. eg, koro.off.connect.com.au:/opt/python/lib/python1.4/site.py > is used by computer systems in 7 different timezones. I hadn't expected that. Of course you could have the site.py file look at the local timezone in a site/timezone. files. > I like Jim's idea of making timezone handling a seperate module - systems > that support timezones reasonably can deal with them, then. Ok. ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org =================