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
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
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
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,
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.
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
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
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().
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
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
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
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
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
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--
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
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
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
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
18 matches
Mail list logo
