Re: DT::F::DBI docs
On 20 Jul 2003 22:53:00 +0200, Claus Färber [EMAIL PROTECTED] wrote: 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]) That is an issue. But that's part of the reason why _dbtype_names() returns an ordered list. For mysqld-foo-bar it may return something like (mysqld-foo-bar, mysqld-foo, mysqld). 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). More likely that the DBI would supply a module that provides mapping between the sets of names. BTW, is there a CVS server for DBI somewhere? No. One day... Tim. Claus [1] I have only looked at unixODBC's source code and not installed it, so I might be wrong there.
DateTime::Format::Common questions...
Okay, I have renamed the module to DateTime::Format::Common and I am getting ready to check in the rough version I have. However I have a few questions I want to get resolved first: 1) Will DateTime 0.14 be the first release with locale support? If so, when will you be bumping the version number (do you usually do that just before release?) I need that version of DateTime as a dependency. 2) Can I add the sub _date_parts_order to the locales? I have the patch to generate_from_icu that does this if you want to see it. Longer term questions (these can be resolved after an initial checkin): 3) I think I need to have additional per-locale information (i.e. AD/BC, AM/PM and now, today, and +- infinity). While AD/BC and AM/PM are in the current locale files I don't think they are in a useful form since there are too many permissible variations. So, I propose to per-locale additional information. However, I am not sure if it makes sense to augment the DT::Locale files or to have a separate DT::F::C::Locale tree. It might be wise to allow for additional day and month name variations too. Obviously it should default to the DT::Locale stuff whenever possible. Thoughts? -ben
Re: DateTime::Format::Common questions...
On Tue, 22 Jul 2003, Ben Bennett wrote: However I have a few questions I want to get resolved first: 1) Will DateTime 0.14 be the first release with locale support? If so, when will you be bumping the version number (do you usually do that just before release?) I need that version of DateTime as a dependency. Yes, and yes. I'll be releasing this stuff soon, I think. 2) Can I add the sub _date_parts_order to the locales? I have the patch to generate_from_icu that does this if you want to see it. Sure, go ahead, but make it date_parts_order. It'll be public, after all. Longer term questions (these can be resolved after an initial checkin): 3) I think I need to have additional per-locale information (i.e. AD/BC, AM/PM and now, today, and +- infinity). While AD/BC and AM/PM are in the current locale files I don't think they are in a useful form since there are too many permissible variations. So you plan to customize this for every locale? Ambitious. So, I propose to per-locale additional information. However, I am not sure if it makes sense to augment the DT::Locale files or to have a separate DT::F::C::Locale tree. It might be wise to allow for additional day and month name variations too. Obviously it should default to the DT::Locale stuff whenever possible. It almost certainly belongs in the DT::Locale code. I'll come up with a way to hook in our extra data to the generation process. There's already something in the generator to override the ICU stuff when it's wrong, so it shouldn't be too hard. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Format::Common questions...
On Tue, Jul 22, 2003 at 11:36:13AM -0500, Dave Rolsky wrote: On Tue, 22 Jul 2003, Ben Bennett wrote: 1) Will DateTime 0.14 be the first release with locale support? If Yes, and yes. I'll be releasing this stuff soon, I think. Ok, in that case I will check it in with a dependency on .14 (which will mean that you can't install it without warnings for a little while). 2) Can I add the sub _date_parts_order to the locales? I have the patch to generate_from_icu that does this if you want to see it. Sure, go ahead, but make it date_parts_order. It'll be public, after all. Will do. 3) I think I need to have additional per-locale information So you plan to customize this for every locale? Ambitious. Well... No. :-) But I plan to have a way to set it for any locale and I will impose upon the nice people on this list who speak other languages to tell me the appropriate values for their locale. For ones we haven't done it will inherit the root locale value. I am also going to make a decent attempt to do the right things with the AM/PM and BC/AD strings. (And I will probably accept the English versions of those for all locales anyway). So, I propose to per-locale additional information. However, I am not sure if it makes sense to augment the DT::Locale files or to have a separate DT::F::C::Locale tree. It might be wise to allow for additional day and month name variations too. Obviously it should default to the DT::Locale stuff whenever possible. It almost certainly belongs in the DT::Locale code. I'll come up with a way to hook in our extra data to the generation process. There's already something in the generator to override the ICU stuff when it's wrong, so it shouldn't be too hard. Ok, if you don't get to it I will take a look sometime. I assume that you want this to come from a separate source than the ICU data? Probably a new directory and file per-override? -ben
ANNOUNCE: Time::Local 1.70_91
Testing on non-UNIX platforms is much appreciated. Any Mac Classic users out there? 1.07_91 2003-07-22 - Henrik refined his edge case fix to work on Win32, which apparently dislikes large negative signed ints. Tests now pass on Win32. More testing on other platforms is appreciated. - Documented Time::Local's behavior when timelocal is called with an ambiguous local time. Some local times occur twice on the same day because a DST change causes the clock to move backwards one earlier. See Ambiguous Local Times in the docs for more details. - Removed the statement under BUGS that the proclivity to croak() is probably a bug. It's not a bug, and it sure isn't going to change at this point in time, anyway! -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Format::Common questions...
I committed it this afternoon (just the Locale change not the Common parser). -ben On Tue, Jul 22, 2003 at 11:27:13AM -1000, Joshua Hoblitt wrote: 2) Can I add the sub _date_parts_order to the locales? I have the patch to generate_from_icu that does this if you want to see it. Sure, go ahead, but make it date_parts_order. It'll be public, after all. And I need it for DT::F::DB2 as DB2 is locale sensitive. -J --
Re: DateTime::Format::Common questions...
I committed it this afternoon (just the Locale change not the Common parser). I'll take a look at soon as I get a chance. Thanks, -J --
Re: DateTime::Precise
On Sun, 20 Jul 2003, Joshua Hoblitt wrote: Did anyone contact the author (Blair Zajac) about renaming this module? Nope, but it'd be nice if he did. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
DT::Incomplete problems with base object
The existing code has some serious problems with the use of the base datetime. For example, the set() method will attempt to unconditionally call set() on the base object. But if the base is 2003-02-10T00:00:00 and one calls $dti-set( day = 30 ) then we'll get a validation error. But if the incomplete object only has a known year, there's no reason to error out (yet). And the docs say you can do set( day = undef ) but that will clearly break badly. So clearly this needs fixing. I'm also not too keen on the way it stores the datetime data in both the incomplete object and the base object. It should all be in one spot, ideally, otherwise we'd end having to re-implement things like quarter and day_of_week and so on. I'm not quite sure how to do this though. Also, the whole attempt to be base class agnostic is only half there, and it makes a bit of a mess of the code. I'd rather take it out, because really implementing it is quite hard, and just makes for overly complex code. I think auto-generating incomplete classes for other calendars is a simpler solution, if it's ever needed. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
