Re: DateTime::TimeZone 0.01_00
On Wed, 5 Feb 2003, Yitzchak Scott-Thoennes wrote:
No, Test::More is loaded by the use Test::More line. This is equivalent
to:
BEGIN { require Test::More; Test::More-import; }
But use_ok doesn't work right since the 'plan tests = 1' hasn't been
done yet. There seems to be a bug in Test::More here...it should have
given a: You tried to run a test without a plan! Gotta have a plan.
I think my version of Test::More lets you call plan after the tests run.
Anyway, I applied John's patch.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00
On Wed, 5 Feb 2003, John Peacock wrote: No, it's clear that the modules are deeply intertwined. My primary concern is that it is currently impossible to install both on a fresh machine without skipping the tests on one of the two (at least to begin with). In my mind, DateTime is the parent module (and DateTime::TimeZone is the crazy cousin ;) and should be installed first. DT::TZ should be dependent on DT, IMHO, not the other way round. That's probably true. The DateTime tests do not fully exercise DateTime::TimeZone (nor would you expect them to). So, how about including only those portions of DT::TZ which are required to pass the DT tests. At a quick glance, that would be TimeZone.pm, UTC.pm, Floating.pm, America/Chicago.pm, and America/NewYork.pm. For that matter, since you know exactly what tests are being performed, you can include exactly the portions of the OlsonDB that are used in the DateTime tests and no more. It seems rather arbitrary to only include Chicago and New York. I can just see all the questions about why the others aren't included! It might be best to just skip those tests if the DateTime::TimeZone package isn't installed, though. The TimeZone.pm that would be distributed with DateTime could be suitably booby-trapped (i.e. warn You must install the full DateTime::TimeZone before using this module). It would be replaced by the full version after DT::TZ was tested and installed. Or distribute everything _but_ the generated files and DateTime::TimeZone::OlsonDB. That way you could do offset only and floating time zone stuff, but to do the historical/rules-based stuff you install a separate package. I would also suggest that the base DateTime::TimeZone release only needs to contain stub modules for the data files and the Makefile.PL should actually be responsible for generating the multitude of PM's prior to testing. You could even include a preamble to Makefile.PL which would download the latest Olson file (if you want to make the installation dependent on Net::FTP). For those that don't have Net::FTP installed, the Makefile.PL could request that they independently download the Olson files themselves and expand them into a top level OlsonDB directory and rerun 'perl Makefile.PL' to build the TZ files. Now that's a PITA! It depends on Net::FTP _and_ Archive::Zip (the TZ data is in a zip file). Too much work for now at least. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00
Dave Rolsky wrote: It seems rather arbitrary to only include Chicago and New York. I can just see all the questions about why the others aren't included! That's just the TZ's you tested, that's all. Any arbitrary bias lies in the scope of the tests, not in my suggestion! duck It might be best to just skip those tests if the DateTime::TimeZone package isn't installed, though. This is a better idea. Or distribute everything _but_ the generated files and DateTime::TimeZone::OlsonDB. That way you could do offset only and floating time zone stuff, but to do the historical/rules-based stuff you install a separate package. This is the best idea of all. How about DateTime::TimeZone contains logic to die with a useful message when a missing TZ is requested, rather than allow Perl's default error to come up and confuse the user. file (if you want to make the installation dependent on Net::FTP). For those that don't have Net::FTP installed, the Makefile.PL could request that they independently download the Olson files themselves and expand them into a top level OlsonDB directory and rerun 'perl Makefile.PL' to build the TZ files. Now that's a PITA! It depends on Net::FTP _and_ Archive::Zip (the TZ data is in a zip file). Too much work for now at least. Granted, but we want people to be able to easily download an updated OlsonDB and regenerate all of the TZ files. I don't suppose you want to keep releasing updates to DT::TZ _every_ time the OlsonDB gets updated. ;~) The idea is empower the user to update their own d**n data files and keep the CPAN distro as small/simple as possible. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00
On Wed, Feb 05, 2003 at 10:58:52AM -0500, John Peacock wrote: Dave Rolsky wrote: Patches welcome ;) The time zone stuff is quite bizarre, I admin. But I really can't think of a way to handle recurring rules (like ongoing DST rules) without being able to date math, for example. How else do you figure out the last Sunday of October? No, it's clear that the modules are deeply intertwined. My primary concern is that it is currently impossible to install both on a fresh machine without skipping the tests on one of the two (at least to begin with). In my mind, DateTime is the parent module (and DateTime::TimeZone is the crazy cousin ;) and should be installed first. DT::TZ should be dependent on DT, IMHO, not the other way round. Er, I may well be missing something as I've not paid attention to this thread, but why not ship them both in the same distribution? Then some tests in t/*.t will test DT and some DT::DZ and both DT and DT::TZ being tested will be the ones in the distribution about to be installed. Tim.
Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00
On Wed, 5 Feb 2003 15:52:46 -0600 (CST), [EMAIL PROTECTED] wrote: The DateTime tests do not fully exercise DateTime::TimeZone (nor would you expect them to). So, how about including only those portions of DT::TZ which are required to pass the DT tests. At a quick glance, that would be TimeZone.pm, UTC.pm, Floating.pm, America/Chicago.pm, and America/NewYork.pm. For that matter, since you know exactly what tests are being performed, you can include exactly the portions of the OlsonDB that are used in the DateTime tests and no more. It seems rather arbitrary to only include Chicago and New York. I can just see all the questions about why the others aren't included! Include them in the distribution for testing purposes but don't install them. It might be best to just skip those tests if the DateTime::TimeZone package isn't installed, though. Even better. The TimeZone.pm that would be distributed with DateTime could be suitably booby-trapped (i.e. warn You must install the full DateTime::TimeZone before using this module). It would be replaced by the full version after DT::TZ was tested and installed. IIUC, that kind of thing causes headaches for those trying to wrap things in an rpm. And some people put *anything* they install into an rpm before installing. Or distribute everything _but_ the generated files and DateTime::TimeZone::OlsonDB. That way you could do offset only and floating time zone stuff, but to do the historical/rules-based stuff you install a separate package. I would also suggest that the base DateTime::TimeZone release only needs to contain stub modules for the data files and the Makefile.PL should actually be responsible for generating the multitude of PM's prior to testing. You could even include a preamble to Makefile.PL which would download the latest Olson file (if you want to make the installation dependent on Net::FTP). For those that don't have Net::FTP installed, the Makefile.PL could request that they independently download the Olson files themselves and expand them into a top level OlsonDB directory and rerun 'perl Makefile.PL' to build the TZ files. Now that's a PITA! It depends on Net::FTP _and_ Archive::Zip (the TZ data is in a zip file). Too much work for now at least. Take a look at e.g. Math::Pari's Makefile.PL if you want to see an example of FTP.
Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00
On Thu, 6 Feb 2003, Rick Measham wrote: I'd argue against this (and possibly the code in TimeZone.pm for handling a time zone of local). I live in Australia and my timezone is +1100. But I host in the US someplace where the machine has a timezone of -0600. I'd prefer to be able to set my local timezone. Maybe ask the user on install but make a default of the machine's local TZ? my $dt = DateTime-new( ..., time_zone = 'Australia/Perth' ); or my $dt = DateTime-new( ..., time_zone = '+1100' ); or my $dt = DateTime-new( ..., time_zone = 39600 ); Just to make a few things clear. 1. The local time is _calculated_ on each request. We don't calculate it when the module is installed and then save it forever. 2. You can change your box's TZ, if it's your box. If not, you can't rely on the local time! 3. We don't need to know your local offset for testing, except to test that setting time_zone = 'local' works. Testing that is not important enough to ask someone to tell us their offset, which they'll get wrong half the time anyway. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00
On Thu, 6 Feb 2003, Rick Measham wrote: I live in Australia and my timezone is +1100. But I host in the US someplace where the machine has a timezone of -0600. I'd prefer to be able to set my local timezone. Maybe ask the user on install but make a default of the machine's local TZ? On 6/2/03 10:14 am, Dave Rolsky at [EMAIL PROTECTED] replied: 1. The local time is _calculated_ on each request. We don't calculate it when the module is installed and then save it forever. 2. You can change your box's TZ, if it's your box. If not, you can't rely on the local time! 3. We don't need to know your local offset for testing, except to test that setting time_zone = 'local' works. Testing that is not important enough to ask someone to tell us their offset, which they'll get wrong half the time anyway. Thanks Dave, I appreciate the clarification. Cheers! Rick There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners
article reviewers wanted
I could use a couple volunteers to review an article I'm writing about date time modules for perl.com. The first few volunteers select will receive my gratitude, a brand new email attachment, and that's about it. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
