Re: DT::F::DBI docs
Tim Bunce [EMAIL PROTECTED] schrieb/wrote: The DBI has a (currently private) method to determine the underlying database type. It was borrowed from DBIx::AnyDBD. Take a look at _dbtype_names() in DBI.pm Yeah, I just updated DT::F::DBI to use that function. I intend to extend it to use $dbh-get_info(17); (=SQL_DBMS_NAME), and give it a public api, in the medium term. One of the problems I can see is that it just returns the type ODBC returns, which is already a problem for MySQL (returns /^mysqld-.*/[1]) and PostgreSQL (returns 'PostgreSQL', not 'Pg'[1]). I'm not sure what DBD::PgPP and DBD::PgSPI return, either. Maybe DBI::_dbtype_names should normalise these DBMS names (e.g. to the corresponding DBD::* driver name, if one exists). BTW, is there a CVS server for DBI somewhere? Claus [1] I have only looked at unixODBC's source code and not installed it, so I might be wrong there. -- http://www.faerber.muc.de
Re: RFC: DateTime::Complex
[EMAIL PROTECTED] schrieb/wrote: I want some feedback on the API, while I write some more tests. Then I'll write the implementation. Well, I've already written some ideas about a possible API in news:[EMAIL PROTECTED]. The most important difference is that I'd like DateTime::Incomplete to actually BE a DateTime: Methods defined by DateTime would just behave as if the base date had been set to 1970-01-01T00:00:00.00...; new methods (or parameters) would make up the interface to the precision fields. So parsers could just return a DT::I object and calling code that does not expect partial dates would still kinda work. On the other hand, it would not be able to handle different calendars. But then, I wonder if it's possible to just build a wrapper for all DateTime::Calendar::* modules. Probably, all modules except DT::C::Julian and DT::C::Christian (which do use 'year', 'month', 'day' like DateTime) will need an own partial class anyway. Claus -- http://www.faerber.muc.de
Re: RFC: DateTime::Complex
* Claus Färber ([EMAIL PROTECTED]) [21 Jul 2003 07:31]: Claus färber [EMAIL PROTECTED] schrieb/wrote: Well, I've already written some ideas about a possible API in news:[EMAIL PROTECTED]. Note: That message is available as http://nntp.x.perl.org/group/perl.datetime/3456 Also at: http://nntp.x.perl.org/group/;[EMAIL PROTECTED] Just pointing that out for future reference =) cheers, -- Iain.
Re: RFC: DateTime::Complex
On Sun, 20 Jul 2003, Claus Färber wrote: The most important difference is that I'd like DateTime::Incomplete to actually BE a DateTime: Methods defined by DateTime would just behave as if the base date had been set to 1970-01-01T00:00:00.00...; new methods (or parameters) would make up the interface to the precision fields. So parsers could just return a DT::I object and calling code that does not expect partial dates would still kinda work. The phrase still kinda work sets of my alarms. I think parsers that can return DT::Incomplete objects need to be very explicit that they do so. In fact, we might even want to insist that parse_datetime _always_ return a complete object or fail, and then offer an additional parse_incomplete_datetime method or something like that. Otherwise people will consistly have to test the returned object's type to make sure it contains the information they need. Since for _most_ people, incomplete dates will be an error condition, I don't want to force them to deal with them. On the other hand, it would not be able to handle different calendars. But then, I wonder if it's possible to just build a wrapper for all DateTime::Calendar::* modules. Probably, all modules except DT::C::Julian and DT::C::Christian (which do use 'year', 'month', 'day' like DateTime) will need an own partial class anyway. Yeah, the idea that core code should be shareable among different calendars is mostly bogus. Ignoring the Julian and Christian modules, most other calendars are sufficiently different that they don't really match up well method-wise with the core code. Java tries to shoehorn them all into one API and it's a horrible disaster. Let's not repeat that mistake. If people _really_ need a DT::Calendar::Mayan::Incomplete, it'll have to stand on its own. OTOH, I really doubt that most calendars will need such a thing. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Format::ISO8601 namepsace
But there's a conflict between several expanded formats: ±_C_CCYYMMDD (= 9 digits) ±_C_CCYYDDD (=8 digits) ±_C_CCYY (= 5 digits) ±_C_CC(= 3 digits) unless you specify the number of digits used for the year/century. The judgment call I've made for DT::F::ISO8601 is expanded formats are only supported with 6 digit years unless a precision for years/centuries is specified. But then, being able to specify the set of ISO formats used might be essential for parsers that use the ISO parser for some formats. Can you give an example of how this might be useful? If someone wants to say only parse this format they can use strptime. (NB: I used CC for century, i.e. year div 100, whereas the ISO standard uses YY, which is very confusing with formats like CC.) Unfortunately not the only confusing thing in the standard. -J --
