Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00
* Yitzchak Scott-Thoennes ([EMAIL PROTECTED]) [06 Feb 2003 09:52]: [...] Take a look at e.g. Math::Pari's Makefile.PL if you want to see an example of FTP. And that module is the root cause of why I had so much trouble installing Module::Signature. In the end I had to build most of Math::Pari manually. It's really not a good way to do things. cheers, -- Iain.
Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00
On Wed, Feb 05, 2003 at 04:39:04PM -0600, Dave Rolsky wrote: On Wed, 5 Feb 2003, Tim Bunce wrote: 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. Assuming that we continue to pre-generate TZ data based on the Olson DB (which may or may not happen), it makes sense to separate them because the two code bases will change at different speeds. One DT::TZ has a firm API and has been reasonably well debugged, it's likely that we'd only have to make a new release when a new Olson DB is released, which happens a few times a year. The DT module, OTOH, may stay in flux longer than DT::TZ, and is likely to continue to stay immature for a longer period of time, meaning initially it'll have many more releases. Eventually, it may become fairly stable (dead? ;) and only see a release very infrequently. Sure. Some modules within the DBI distribution change very rarely, but I still ship them within the DBI distribution as they're closely related and it's a convienience for the user. If size is the issue, why not generate the DT::TZ::foo modules when the user runs perl Makefile.PL? That would make the distribution much smaller. That's that's not okay then I'd suggest creating distributions for each of DT::TZ::Africa::*, DT::TZ::Europe::*, DT::TZ::Pacific::* etc. Add a Bundle::DateTime::TimeZone module to automate the fetch/install of all of them. Then ship the core DT::TZ modules plus one set of zones (say DT::TZ::America) in the DT distribution. Or, then again, given the relative simplicity/portability of the DT::TZ code you could just keep doing what you're doing... :) Tim.
Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00
On Wed, 5 Feb 2003, Yitzchak Scott-Thoennes wrote: 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. I've used Net::FTP many times. But adding additional dependencies just to _install_ the module (and also relying on the user being able to connect via FTP to an external server _at the time of install_) is probably not a great idea. I could ship the Olson db files, which are a bit more compact than the generated Perl modules. But as I said to Tim, I'd like to wait on addressing this until after I'm sure the code works, if factored properly, etc. -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
Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00
Please try them out and let me know what you think, what bugs you find, etc. A 'Teehee' from the docs: $dow = $dt-day_of_week;# 1-7 (Monday is 1) ... $day_name = $dt-day_name # Sunday, Monday If Monday=1 and Sunday=7 then shouldn't the example of the second line be 'Monday, Tuesday'? Gee I hate this ISO thing that makes (Monday .. Sunday) = (1 .. 7). I'm not arguing for changing our modules to be 'old style' .. we're all just going to have to get used to the weekend being at (shock horror) the end of the week. Cheers! Rick Measham 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
Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00
On Wed, 5 Feb 2003, Rick Measham wrote: Please try them out and let me know what you think, what bugs you find, etc. A 'Teehee' from the docs: $dow = $dt-day_of_week;# 1-7 (Monday is 1) ... $day_name = $dt-day_name # Sunday, Monday If Monday=1 and Sunday=7 then shouldn't the example of the second line be 'Monday, Tuesday'? Yep, that is more consistent. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
