Re: DateTime marches on
Matt Sisk wrote: So I quickly made an update, and now HTML::CalendarMonth 1.11 is fully powered on the i8n back end by DateTime::Locale. And it works splendidly. That's funny! I noticed 1.10 on CPAN's Recent page, took a look at it and didn't download it, _because it didn't use DateTime_. Glad to see you came to your senses... ;-) John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: ANNOUNCE: DateTime::Locale 0.20
On Sat, 26 Feb 2005, Dave Rolsky wrote: - Uses much newer (August, 2004) data from ICU. I just noticed that this causes a DT::Set test to fail, because the pt_BR locale data changed. Flavio, I checked in a fix for this (to use en_US, which hasn't ever changed). I sent DateTime::Set 0.20 to CPAN: 0.20 2005-02-28 - changed tests to use en_US instead of pt_BR (which changes every year) - by Dave Rolsky. - optimized SpanSet methods for special cases: start_set() end_set() contains( $dt ) intersects( $dt ) - added an example to count(), by David Nicol. - added a note about how the result of min()/max() is just a copy of the actual set boundary. Reported by Ron Hill. - Flavio S. Glock
DateTime objects are necessarily huge?
hi dave and all :)
so, we're starting to implement new date/time handling here at the office.
the DateTime suite seemed the natural way to go for obvious reasons (it
didn't exist or was relatively new the last few cycles, should you ask).
however, in implementing it we found something that might prevent us from
being able to deploy it at all - DateTime objects are _huge_ for non-UTC
timezones. consider:
use DateTime;
use Data::Dumper;
$dt = DateTime-now;
print Dumper $dt;
sleep 5;
$dt-set_time_zone('Europe/London'); # UTC equivalent
print Dumper $dt;
now, because we have a ton of different things that need to be individually
wrapped in objects, this means a megaton of data will be floating around our
model objects, and even more floating around in our object caches.
so, the question I have is whether all that data is necessary to store in
the object upon creation? that is, is it all precalculations such that we
can trade in object size for runtime efficiency? perhaps not in the code as
it exists now, but is that something DateTime is open to, or is that data
more essential to the object than I realize?
--Geoff
Re: DateTime objects are necessarily huge?
On 2/28/05 9:42 AM, Geoffrey Young wrote: DateTime objects are _huge_ for non-UTC timezones. consider: [...] print Dumper $dt; I always just assumed that those giant structures exist once in memory and are simply referenced by each DT object. I never bothered to actually check, but c'mon, how could it be otherwise? :) -John
Re: Calculating number of days to a given birthday
On Mon, Feb 28, 2005 at 07:43:47AM -0800, Hill, Ronald wrote:
Sven Ingebrigt Ulland wrote:
For some time now, I've been trying to figure out how
to calculate how many days left before a given date
of birth, to easily keep track of my friends' birthdays.
This might get you started. (untested)
use strict;
use warnings;
use DateTime;
use DateTime::Format::Strptime;
use DateTime::Duration;
my $dt = DateTime-today();
my $Strp = new DateTime::Format::Strptime(
pattern = '%Y-%m-%d',
time_zone = 'floating',
);
my %family = ();
while (DATA) {
my ( $name, $date ) = split ();
my $birthday = $Strp-parse_datetime($date);
So far I'm with you, but the following line,
my $current_birthday = $birthday-clone()-set( year = $dt-year );
..assumes that the year of birth has the same leap year properties as
this year. In practice, this will break if birthday is after 28th of
February, and:
-year of birth is a leap year, while this year is not.
-year of birth is a normal year, while this year is a leap year.
Both of the above are only valid for some today dates. To tell
you the truth, I tried to think about it now, but my brain has
trouble visualizing it. I might be totally wrong, or slightly
off. A flawless pseudo algorithm for this would be nice to see,
if your suggestion is indeed flawed, that is.
if ( $dt $current_birthday ) {
$current_birthday-add( DateTime::Duration-new( years = 1 ) );
}
Here is a step by step example for when this approach might
fail (mostly for my understanding):
Today = 2007-03-02
DOB = 1981-03-01 #Date of birth.
First, we set the year of birth to this year:
DOB = 2007-03-01
Now, this date has already passed in this year, so we add a year:
DOB = 2008-03-01
Now, when we calculate the duration from Today to DOB, it will
actually include the 29th of February since 2008 is a leap year,
and thus miss by one day. Again, I might be totally off here;
please comment.
$family{$name} = $current_birthday;
}
print map {
$_, : , $family{$_}-delta_days($dt)-in_units('days'),
days til birthday\n;
} sort keys %family;
__DATA__
wife 1965-06-10
son 1997-06-27
daughter 1993-08-22
I hope this helps :-)
Thank you very much for the code suggestion, Ron. However,
there doesn't seem to be a really simple solution (a few
statements) to this problem, if in fact my thoughts are
correct. One of these days I'll see if I can understand
the thinking behind the problem, and set up the proper
conditional expressions needed. Am I free to use your
code?
regards,
Sven
Re: Calculating number of days to a given birthday
On Mon, Feb 28, 2005 at 05:43:52PM +0100, Sven Ingebrigt Ulland wrote: On Mon, Feb 28, 2005 at 07:43:47AM -0800, Hill, Ronald wrote: Sven Ingebrigt Ulland wrote: For some time now, I've been trying to figure out how to calculate how many days left before a given date of birth, to easily keep track of my friends' birthdays. Here is a step by step example for when this approach might fail (mostly for my understanding): Today = 2007-03-02 DOB = 1981-03-01 #Date of birth. First, we set the year of birth to this year: DOB = 2007-03-01 Now, this date has already passed in this year, so we add a year: DOB = 2008-03-01 Now, when we calculate the duration from Today to DOB, it will actually include the 29th of February since 2008 is a leap year, and thus miss by one day. Again, I might be totally off here; please comment. I just realized how completely wrong I was. Of course it includes the leap year, and it should! Actually, I've been thinking about this problem in the wrong way all along. Please forgive my utter ignorance here. Thanks again for the code, which I now believe to be correct. shameful regards, Sven
Re: DateTime objects are necessarily huge?
On Mon, 28 Feb 2005, Geoffrey Young wrote: now, because we have a ton of different things that need to be individually wrapped in objects, this means a megaton of data will be floating around our model objects, and even more floating around in our object caches. so, the question I have is whether all that data is necessary to store in the object upon creation? that is, is it all precalculations such that we can trade in object size for runtime efficiency? perhaps not in the code as it exists now, but is that something DateTime is open to, or is that data more essential to the object than I realize? The hugeness is the DateTime::TimeZone object, not DateTime itself. Those are all singletons, so you only pay the price once per time zone. The ultimate fix is to implement this code in C with C data structures, I think. Not doing the precalculations might be possible, but it'd make many things much slower, since the code that I use to generate this data is completely unoptimized. Plus it's ugly as hell ;) Making loading the pre-calculated data _optional_, as opposed to removing it entirely, would be best. I'm open to a patch, but it's a lot of work, and not something I'd have time to do any time soon. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: ANNOUNCE: DateTime 0.28
On Sun, Feb 27, 2005 at 11:58:22PM -0600, Dave Rolsky wrote: 0.282005-02-27 [ ENHANCEMENTS ] - The era names for the era() method are now retrieved from the DateTime.pm object's associated locale. The old era() method, which was hard-coded to use BCE and CE, is renamed secular_era(). Why? I thought one of the selling points of CE was that people were free to interpret it as Xtian Era or Common Era as they please. I'd have left it as generic era().
Re: DateTime objects are necessarily huge?
On Mon, 28 Feb 2005, Geoffrey Young wrote: The hugeness is the DateTime::TimeZone object, not DateTime itself. Those are all singletons, so you only pay the price once per time zone. ok, but how does that affect storable-style serializations? I noticed that you have some storable hooks, but I didn't see exactly how it worked. Unfortunately, it's not possible to retain singleton-ness after a freeze/thaw with Storable. This is because of the way Storable's internals work. I _think_ this could be changed, and I tried doing so, but couldn't quite figure it out. I brought it up on P5P a while back (maybe a year) but nobody responded. I'm open to a patch, but it's a lot of work, and not something I'd have time to do any time soon. I can take a crack at it, but it wasn't clear exactly how these things interlaced, or even what the span foo was. if you could sorta point me in the right direction for implementing it in a way you'd prefer I'll have a go at it. Start by taking a look at tools/parse_olson and DateTime::TimeZone::OlsonDB. The latter isn't all that well documented (to say the least), unfortunately. I think to make this work we'd have to break up the rules for a given zone and store them in the file, then parse them on the fly as needed. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: ANNOUNCE: DateTime 0.28
On Mon, 28 Feb 2005, Yitzchak Scott-Thoennes wrote: On Sun, Feb 27, 2005 at 11:58:22PM -0600, Dave Rolsky wrote: 0.282005-02-27 [ ENHANCEMENTS ] - The era names for the era() method are now retrieved from the DateTime.pm object's associated locale. The old era() method, which was hard-coded to use BCE and CE, is renamed secular_era(). Why? I thought one of the selling points of CE was that people were free to interpret it as Xtian Era or Common Era as they please. I'd have left it as generic era(). Well, generic era() is now coming from the locales, which I think is the right thing to do. I named it secular_era() to distinguish it from christian_era(). -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: DateTime objects are necessarily huge?
On 2/28/05 1:26 PM, Dave Rolsky wrote: On Mon, 28 Feb 2005, Geoffrey Young wrote: The hugeness is the DateTime::TimeZone object, not DateTime itself. Those are all singletons, so you only pay the price once per time zone. ok, but how does that affect storable-style serializations? I noticed that you have some storable hooks, but I didn't see exactly how it worked. Unfortunately, it's not possible to retain singleton-ness after a freeze/thaw with Storable. This is because of the way Storable's internals work. I _think_ this could be changed, and I tried doing so, but couldn't quite figure it out. I brought it up on P5P a while back (maybe a year) but nobody responded. Can't you just nuke the giant DT:TZ ref before freezing and have it auto-re-vivify when first used after it's thawed? IOW, save the TZ string (floating, local, America/Chicago) and then re-grab a ref to the DT::TZ singleton as needed. That way, you don't have to freeze the DT::TZ at all. Of course, I don't know how flexible the Storable hooks are... -John
Re: DateTime objects are necessarily huge?
On Mon, 28 Feb 2005, John Siracusa wrote: Can't you just nuke the giant DT:TZ ref before freezing and have it auto-re-vivify when first used after it's thawed? IOW, save the TZ string (floating, local, America/Chicago) and then re-grab a ref to the DT::TZ singleton as needed. That way, you don't have to freeze the DT::TZ at all. Oh yeah. That's what it already does ;) It should do that, but there seems to be something wrong: $dt = DateTime-today; $dt-set_time_zone( America/Chicago ); print $dt-STORABLE_freeze, \n ' utc_rd_days:732005|utc_rd_secs:0|rd_nanosecs:0|version:0.28DateTime::Locale::root=HASH(0x838d4a4)DateTime::TimeZone::America::Chicago=HASH(0x8328ca0)SCALAR(0x8328da8) - Flavio S. Glock
Re: DateTime objects are necessarily huge?
Oh yeah. That's what it already does ;) It should do that, but there seems to be something wrong: with recent versions (the ones that existed before this weekend's release) I get very similar sizes using nstore: -rw-rw-r--1 geoffgeoff 180 Feb 28 14:02 stored-nonutc -rw-rw-r--1 geoffgeoff 159 Feb 28 14:02 stored-utc with DT 0.12 (an old version I happen to have lying around) it's much different: -rw-rw-r--1 geoffgeoff 31143 Feb 28 13:59 stored-nonutc -rw-rw-r--1 geoffgeoff 820 Feb 28 13:59 stored-utc so somewhere in there it looks like things got much better, and that things are working well currently. but maybe using freeze/thaw has different results. --Geoff
Re: DateTime objects are necessarily huge?
On Mon, 28 Feb 2005, Geoffrey Young wrote: It should do that, but there seems to be something wrong: with recent versions (the ones that existed before this weekend's release) I get very similar sizes using nstore: -rw-rw-r--1 geoffgeoff 180 Feb 28 14:02 stored-nonutc -rw-rw-r--1 geoffgeoff 159 Feb 28 14:02 stored-utc with DT 0.12 (an old version I happen to have lying around) it's much different: -rw-rw-r--1 geoffgeoff 31143 Feb 28 13:59 stored-nonutc -rw-rw-r--1 geoffgeoff 820 Feb 28 13:59 stored-utc so somewhere in there it looks like things got much better, and that things are working well currently. but maybe using freeze/thaw has different results. All the Storable methods go through those hooks, so it should always work. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: DateTime objects are necessarily huge?
On Mon, 28 Feb 2005 [EMAIL PROTECTED] wrote: On Mon, 28 Feb 2005, John Siracusa wrote: Can't you just nuke the giant DT:TZ ref before freezing and have it auto-re-vivify when first used after it's thawed? IOW, save the TZ string (floating, local, America/Chicago) and then re-grab a ref to the DT::TZ singleton as needed. That way, you don't have to freeze the DT::TZ at all. Oh yeah. That's what it already does ;) It should do that, but there seems to be something wrong: $dt = DateTime-today; $dt-set_time_zone( America/Chicago ); print $dt-STORABLE_freeze, \n ' utc_rd_days:732005|utc_rd_secs:0|rd_nanosecs:0|version:0.28DateTime::Locale::root=HASH(0x838d4a4)DateTime::TimeZone::America::Chicago=HASH(0x8328ca0)SCALAR(0x8328da8) Note that this was added in DT::TZ 0.26. DT.pm itself didn't have to be changed, IIRC. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: DateTime objects are necessarily huge?
On Mon, 28 Feb 2005 [EMAIL PROTECTED] wrote: On Mon, 28 Feb 2005, John Siracusa wrote: Can't you just nuke the giant DT:TZ ref before freezing and have it auto-re-vivify when first used after it's thawed? IOW, save the TZ string (floating, local, America/Chicago) and then re-grab a ref to the DT::TZ singleton as needed. That way, you don't have to freeze the DT::TZ at all. Oh yeah. That's what it already does ;) It should do that, but there seems to be something wrong: $dt = DateTime-today; $dt-set_time_zone( America/Chicago ); print $dt-STORABLE_freeze, \n ' utc_rd_days:732005|utc_rd_secs:0|rd_nanosecs:0|version:0.28DateTime::Locale::root=HASH(0x838d4a4)DateTime::TimeZone::America::Chicago=HASH(0x8328ca0)SCALAR(0x8328da8) Note that this was added in DT::TZ 0.26. DT.pm itself didn't have to be changed, IIRC. I'm sorry - I just installed a new DT::TZ from CPAN and I'm still getting stringified references instead of names. - Flavio S. Glock
Re: DateTime objects are necessarily huge?
On Mon, 28 Feb 2005 [EMAIL PROTECTED] wrote: Note that this was added in DT::TZ 0.26. DT.pm itself didn't have to be changed, IIRC. I'm sorry - I just installed a new DT::TZ from CPAN and I'm still getting stringified references instead of names. That's cause STORABLE_freeze returns some data and some objects. Storable will then look for hooks in the returned objects. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
ANNOUNCE: DateTime::Locale 0.21
0.21 2005-02-28 - Fix era() method for year 0. This fixes a test failure in DateTime 0.28. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
