A long time in coming ...
0.302005-12-22
[ ENHANCEMENTS ]
- Expanded and rewrote the docs on date math to try to explain exactly
how DateTime.pm works, and in particular cover the problems DST
introduces to various types of date math. The docs now also include
some specific
On Wed, 21 Dec 2005, Rick Measham wrote:
So now I come back to DateTime::Decorated that I started back in June to
deafening silence... Unless I get any objections I'll get it ready to go, and
release GPS and WeekConstructor at the same time.
my $DateTimeGPS = DateTime::Decorated( with =
[cc'ing back to the list]
On Fri, 16 Dec 2005, Tatsuhiko Miyagawa wrote:
Sorry for the dumb question.
Suppose I have $year == 2005 and $week_number == 42, how can I get the
date range (or first day) of the week number, in DateTime?
There's no really nice way to do this right now, though you
0.39 2005-06-05
- This release is based on version 2005o of the Olson database.
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
I finished moving the site over to a wiki today. I copied all the old
content into pages. I also reproduced most of the layout. There's a
module, Kwiki::Theme::DateTime, in the CVS repo that implements the look
and feel for the site.
-dave
On Thu, 24 Nov 2005, Randal L. Schwartz wrote:
Dave == Dave Rolsky [EMAIL PROTECTED] writes:
Dave I was thinking this might be a good idea. The one thing we'd lose is
Dave the tests built into the FAQ for testing examples. This is a really
Dave nice feature, but I think the benefits
On Wed, 23 Nov 2005, Flavio S. Glock wrote:
2005/11/21, Rick Measham [EMAIL PROTECTED]:
It's a pity to lose the tests though ..
How about a WWW::Mechanize script that would download the FAQ page and
run tests?
(the script itself would be in a wiki page, such that a volunteer
would easily
I was thinking this might be a good idea. The one thing we'd lose is the
tests built into the FAQ for testing examples. This is a really nice
feature, but I think the benefits of moving to a wiki are bigger.
Any objections?
-dave
/*===
On Mon, 21 Nov 2005, Dave Rolsky wrote:
I was thinking this might be a good idea. The one thing we'd lose is the
tests built into the FAQ for testing examples. This is a really nice
feature, but I think the benefits of moving to a wiki are bigger.
There's probably a bunch of other stuff
0.38 2005-11-21
- Trying to create a DateTime object during DST exactly 11 years in
the future (really, 1 year after the end of the pre-generated TZ
change data that ships in the package) cause an error. Reported by
Daniel B Boorstein.
- This release is based on version 2005n of the Olson
I think I've hit upon a fairly sane answer, although it makes the
internals of DateTime.pm even yuckier than before (which may be hard to
imagine if you've already poked around in some of the methods ;)
I've summarized it on the wiki here:
http://datetime.perl.org/wiki/index.cgi?MathProblems
On Mon, 21 Nov 2005, Rick Measham wrote:
mathieu longtin wrote:
Cause time since the epoch doesn't measure leap seconds. See in the
DateTime manual, under the epoch() method description.
I'm aware that it doesn't measure them ... but I'm wondering why? Surely that
makes it Capital-W-Wrong.
On Sat, 5 Nov 2005, Mike Schilli wrote:
Adding seconds to a date gets stuck when it reaches a leap second:
use DateTime;
my $dt = DateTime-new(
year = 1972,
month = 12,
day = 31,
hour = 23,
minute= 59,
second= 55,
time_zone
On Sat, 5 Nov 2005, Mike Schilli wrote:
Looks like this example doesn't work:
Leap Seconds and Date Math
The presence of leap seconds can cause some strange anomalies in date
math. For example, the following is a legal datetime:
my $dt = DateTime-new( year = 1971, month =
On Tue, 11 Oct 2005, Boorstein, Daniel B wrote:
In putting together a new machine I've installed the latest versions of
DateTime and DateTime::TimeZone. Code that was working (using DateTime
0.22, DateTime::TimeZone 0.30) is now failing. Example:
perl -MDateTime -e 'my $dt = DateTime-new(year
On Thu, 22 Sep 2005, Sam Tregar wrote:
Hello all. I'm working on an application which will provide a flexible
data upload system. Users will upload CSV files containing data from
other systems and they'll provide meta-data which will allow the
application to load that data into the system.
On Tue, 13 Sep 2005, Bill Moseley wrote:
set_time_zone returns undef if the new time zone is the same as the
old. Is that by design?
I got caught doing this:
return $self-class_time-set_time_zone( $tz );
in the cases when $tz was not changing.
Nope, that's definitely a bug.
-dave
On Wed, 7 Sep 2005, Matt Sisk wrote:
Dave Rolsky wrote:
I will make a list of all the problems I've run across so far, along with
examples that demonstrate them. Anyone who can come up with a solution
that handles all of these problems is a far smarter person than I am ;)
It might already
On Wed, 7 Sep 2005, Rick Measham wrote:
Dave Rolsky wrote:
Having a wiki would make this easier ;) I'll look for a place to set one
up.
I'm happy to host one (something with auth and good perl rendering) at
http://datetime.isite.net.au/ if you'd like.
I realized that datetime.perl.org
http://datetime.perl.org/wiki/
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
On Tue, 6 Sep 2005, Rick Measham wrote:
You always suggest splitting it up into more packages, but that doesn't
necessarily help. I think the real problem here is that a lot of people
just want date math, and they don't care about times. The real split
should probably be a date-only module
On Mon, 5 Sep 2005, Joshua Hoblitt wrote:
On Mon, Sep 05, 2005 at 11:49:33PM -0500, Dave Rolsky wrote:
my $dt = DateTime-new( year = 2003, month = 9, time_zone =
'America/Chicago' );
$dt-add( months = 3 );
Now what do you expect that to produce? I suspect 99% of users expect
On Tue, 6 Sep 2005, renard wrote:
The results should be obviously correct and not throw an unexpected curve.
When I find the difference between 2 dates I expect to obtain the same dates
when I add/subract the difference. If I don't then it raises a red flag on
the correctness of adding/
On Tue, 6 Sep 2005, Joshua Hoblitt wrote:
No, they'll notice, but the workarounds for subtractions are
well-documented.
So why is that better than making subtractions work 'as expected' and
documenting the work arounds for addition?
Because AFAICT subtractions just _cannot_ work as
On Wed, 7 Sep 2005 [EMAIL PROTECTED] wrote:
Dave Rolsky said:
The more I think about this the more I'm convinced that the idea of
datetime subtraction producing something other than seconds is a
convenient fiction. Similarly, date subtraction producing something other
than a count of days
So I have it to a state where I'm pretty happy with the code and docs. It
won't satisfy everyone, but that's more or less impossible given how many
correct ways of doing datetime math I've come up with.
Here's the summary:
- Adding a duration contains to work the same way as it always did,
On Mon, 5 Sep 2005, Dave Rolsky wrote:
I tested the new version with all the Calendar Event modules in the DT CVS
repo, and they all passed. However, DateTime::Format::Duration from CPAN
does not pass.
Oops, meant to write more.
Rick, I took a look at the code where it's failing and I'm
On Tue, 6 Sep 2005, Rick Measham wrote:
Once 0.30 is out, I'll put some effort into DT:F:D however it won't be this
weekend as my wife has booked a holiday for the weekend and she'll be mildly
annoyed if I work on DateTime :)
Cool, just wanted to give you a heads up that it'd break your
On Mon, 5 Sep 2005, Joshua Hoblitt wrote:
On Mon, Sep 05, 2005 at 03:15:35PM -0500, Dave Rolsky wrote:
This means that if you do subtract_datetime on two objects you end up with
this situation:
$dur = $dt2 - $dt1
$dt1 + $dur != $dt2
$dt2 - $dur != $dt1
But honestly I don't really think
On Tue, 6 Sep 2005, Rick Measham wrote:
So, assuming America/Chicago: (2003-12-01) - (2003-09-01) will return a
duration representing 2 months, 29 days and 23 hours?
Yes, _but_ the docs suggest that if you don't like this you probably
wanted _date_ math (not datetime) in the first place, and
On Tue, 6 Sep 2005, Dave Rolsky wrote:
Then again, I wonder if durations shouldn't be removed altogether and put
into separate packages that allowed people to choose their math
assumptions.
You always suggest splitting it up into more packages, but that doesn't
necessarily help. I think
Is there any particular reason this isn't supported other than lack of
tuits? Pg can return infinity or -infinity for a datetime, so it'd be
nice to turn that into the appropriate DateTime::Infinite object (and vice
versa).
Claus, I can make the changes myself if you'd like.
-dave
On Thu, 18 Aug 2005, Roderick A. Anderson wrote:
If I have two datetime objects, $now_dt and $suspend_dt, both truncated to
minute, do I use a string comparison ge, le, eq ; numeric =, =, == ; or
something all together different that I didn't see in the docs?
Heck which is greater?
On Fri, 2 Sep 2005, Daisuke Maki wrote:
Want to try out this patch?
I'll release it if it works (I personally don't use infinite datetime on Pg,
so it would be better if you check it out...)
Yep, works for me. I'd definitely appreciate a release soon, since it'd
be really handy for $DAYJOB
On Tue, 16 Aug 2005, Dave Rolsky wrote:
On Tue, 16 Aug 2005, Eugene van der Pijll wrote:
This suggests that the proper solution is not to have two methods, one
for local subtraction and one for utc subtraction; but to do
calculations with hours/mins/seconds in utc, and days/months/years
There's now a branch called xs-version. I need to make a new release (new
Olson db was just released) and the XS code isn't yet stable/faster so I'm
going to base this release on 0.36.
-dave
/*===
VegGuide.Org
0.37 2005-08-22
* Make sure that provided time zone names are valid, because
DateTime::TimeZone uses them in an eval. If you were passing
user-provided data directly to DateTime::TimeZone-new, someone could
give a string like America/Chicago; system 'rm -rf /';, which would
be bad.
On Wed, 17 Aug 2005, Rick Measham wrote:
.. to combat this, I looked at Dave's Class::ClassDecorator and released a
proof-of-concept DateTime::Decorated module on this mailing list.
Unfortunately Class::ClassDecorator requires that all the decorating
classes play nice by using NEXT or super,
On Wed, 17 Aug 2005, Rick Measham wrote:
I'm cool with that .. I guess then that each Format module that is 'use'd
would somehow publish methods to the DateTime Class rather than an object?
I'm not sure how this would be technically done using your example code ..
So now if you use a CPAN
On Tue, 16 Aug 2005, Dan Horne wrote:
Alas, I was hoping that somehow local would just read the time set on the
clock rather than erroring. Thanks Rick,
You can get that from this:
my $dt = DateTime-now( time_zone = $my_time_zone );
So if you explicitly give it the time zone it'll give
On Mon, 15 Aug 2005, Dave Glasser wrote:
I'm getting a failing test on line 318 of t/09changes.t in DateTime::TimeZone;
the line is:
like( $@, qr/Invalid local time .+/, 'exception for invalid time
produced via add' );
and $@ is not being set to anything.
This is with DateTime
So it turns out that DT.pm has basically been buggy with regards to date
math for any timezone with a DST change basically forever.
The problem is that sometimes people want to do math in terms of the local
time (the clock display time) and sometimes in terms of UTC time (the
actual passing
On Tue, 16 Aug 2005, Eugene van der Pijll wrote:
John Siracusa schreef:
Any chance of the great dates without times vs. datetimes split happening
in DateTime for Perl 5? That'd solve a lot of problems too. Maybe some of
the DateTime::Incomplete stuff could help here?
Dave, are you working
On Wed, 10 Aug 2005, Flavio S. Glock wrote:
I'm debugging a new failure in DateTime::Set t/15time_zone.t.
It fails with an infinite loop in this recurrence:
my $months = DateTime::Set-from_recurrence(
recurrence = sub {
$_[0]-truncate( to = 'month' )-add(
On Mon, 25 Jul 2005, Joshua Hoblitt wrote:
a) do nothing... nobody else seems to have noticed
b) document the limited precision issue
c) change the API to some awful Fortranish a part + b part to preserve
precision
d) turn the epoch parameter into a Math::BigFloat so a high resolution
'string'
On Mon, 8 Aug 2005, John Siracusa wrote:
On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote:
Does anyone object to adding Math::BigFloat as a
prereq?
What are the performance/memory implications? I don't object to the prereq,
but I would like to know if we're in for any new speed/bloat issues
On Sun, 31 Jul 2005, Eugene van der Pijll wrote:
Dave Rolsky schreef:
http://www.post-gazette.com/pg/05210/545823.stm
Unfortunately it wouldn't make DT.pm any simpler, since we'd still have
the existing leap seconds to account for.
And we'd have to implement leap hours in UTC... (Though
http://www.post-gazette.com/pg/05210/545823.stm
Unfortunately it wouldn't make DT.pm any simpler, since we'd still have
the existing leap seconds to account for.
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to
On Fri, 29 Jul 2005, Ortwin Wagner wrote:
using the time::local modul I found that the timelocal() function causes 8
error messages each time the function is used. If in the shebang the option
-w is removed the error messages in the http server log stop.
How about some code? I'd break into
On Fri, 22 Jul 2005, Joshua Hoblitt wrote:
Dave has started down a path for something which is/will be engineered
very differently from the p5 version of DateTime. I'm not saying this
is a bad thing, especially in the long run, I'm just trying to start a
discussion point on what the 'best' way
On Fri, 22 Jul 2005, Joshua Hoblitt wrote:
It appears as if Pugs is very close to being able to host a major
framework like DateTime. I think that it's 'time' to start considering
porting DateTime to Perl6. Even if for no other reason then to help
debug Pugs. The big question that I believe
On Wed, 20 Jul 2005, Daisuke Maki wrote:
On a related note, seems like Dave's change to Build.PL only works with the
latest (dev?) Module::Build (some missing methods are reported as errors in
my environment). If you do not have the correct version of Module::Build, you
may need to revert
On Thu, 21 Jul 2005, Rick Measham wrote:
Joshua Hoblitt wrote:
What about DateTime::Mock? Since that would make it clear that this
isn't /really/ a DT object.
Thanks Joshua,
I want to wrap this up and release so there's 24 hours to finalise the name.
Here's the names I like thus far:
On Mon, 11 Jul 2005, Daisuke Maki wrote:
So I spent the last four days trying to fix whatever it was that causing
this seeming increase in memory size, and I'm still at quite a loss.
I've optimize the memory usage in the code as much as I could, and I'm
pretty much out of ideas, so I've posted
On Mon, 11 Jul 2005, Matt Sisk wrote:
At some point a while back, I analyzed the data structures used in forming the
timezone objects and found that there was a lot of redundant structures,
particularly in cases where you were loading a large number of zones. I hacked
the data structure to
On Fri, 8 Jul 2005, Rick Measham wrote:
It's been discussed before, and the main reason is below. There's just no way
to properly parse a datetime. You can make 'best guesses'. But you should
probably use something else to make your guesses, then offer them to the user
to pick which they
On Fri, 8 Jul 2005, Daisuke Maki wrote:
I'm happy to announce that I just commited the first cut of the new XS
implementation of DateTime::TimeZone to CVS.
For now the only thing I ported are a few methods and the $spans structure,
which used to be a AoA. This is now a list of C structs, and
On Thu, 7 Jul 2005, Rick Measham wrote:
Dave Rolsky wrote:
It has a pretty different API, in that it's new() constructor accepts
anything without validation.
I suppose it could check for extra args and call DateTime::Fat-new() if
needed.
I think that'd be a possibility, but it'd have
On Wed, 6 Jul 2005, Rick Measham wrote:
I've included the output of the attached script below. I was surprised to
note that even after the rebless was included in the tests, the Diet version
was still *much* quicker.
I'm not sure what you mean. It's much quicker for operations that occur
On Wed, 6 Jul 2005, Flavio S. Glock wrote:
This is the beginning of the Set::Infinite and DateTime::Set packages
for Perl 6. There is not much written yet.
Set::Infinite will probably be split in 3 classes, mirroring the
DateTime::Set package structure:
- Set::Span / DateTime::Span - a single
On Thu, 7 Jul 2005, Rick Measham wrote:
So .. would this module actually get used by anyone but me? If so I'll go
ahead and polish it off.
It sounded like people were interested. And maybe it's a if you build it
they will come thing ;)
Anyway, go for it and let's brainstorm on a better
On Mon, 4 Jul 2005, Sam Vilain wrote:
Well, I think what you started already has some serious mistakes. For one,
the Huffman coding is backwards. You've used Date for a generic
interface, which is something that only calendar authors need to implement,
and then used Date::Gregorian for the
[cc'ing back to the datetime list]
On Fri, 1 Jul 2005, Sam Vilain wrote:
I may have been quite vocal in the past about the practical failings
of DateTime for Perl 5, but as I'm sure we both know, the API has needed
Actually, I don't remember you saying anything, but maybe it was a while
On Tue, 28 Jun 2005, Daisuke Maki wrote:
Anyone have any ideas why? I was hoping to use it as an example in my
datetime talk at YAPC but oh well.
Dave, I seem to have found it. DT::Util::Calc's mod() function behaves oddly
when using $bigint-bmod($mod).
Can you confirm that this will
On Tue, 28 Jun 2005, Hill, Ronald wrote:
I am testing this and am unable to install.
DateTime-calendar-chinese requires
'DateTime::Event::Chinese' = '= 0.04',
But I checked CPAN it only goes to version 0.03
Have you not yet uploaded the new version to CPAN yet?
I noticed this too. It
On Fri, 17 Jun 2005, Jonathan Leffler wrote:
DATE has components from year down to day; TIME has components from hour
down to microseconds (or finer); and TIMESTAMP contains components from
How can you have a time with a time zone when it has no date? Weirdness.
I would certainly like to
On Thu, 16 Jun 2005, Yitzchak Scott-Thoennes wrote:
On Wed, Jun 15, 2005 at 02:17:29PM -0500, Dave Rolsky wrote:
- Work with just dates and do date math on them (at the level of days,
months years). The current implementation is quite broken for this
purpose, because when you assign a non
On Thu, 16 Jun 2005, Rui Fernandes wrote:
4) The last:
my $last_observance = bless( { #DON'T HAVE A CLUE WHAT THIS IS...
'format' = 'WE%sT',
'gmtoff' = '0:00',
'local_start_datetime' = bless( {
'formatter' = undef,
'local_rd_days' = 728749,
'local_rd_secs' = 7200,
On Wed, 15 Jun 2005, Rick Measham wrote:
renard wrote:
I quote from perldoc DateTime:
DateTime.pm always adds (or subtracts) days, then months, minutes, and
then seconds. If there are any boundary overflows, these are normalized
at each step.
Dave, if you're following this, can you tell
So there's been a bunch of date math + TZ related bugs lately in
DateTime.pm, and more to be resolved.
I think the fundamental problem is that DateTime.pm is trying to cover a
few too many bases in one simple API.
There are a bunch of things people would like to be able to do:
- Work with
On Tue, 31 May 2005, J. Alexander Docauer wrote:
In other words, the duration is the actual number of hours that passed, aka
the floating point number of rotations of the earth on its axis that have
occurred. If it were to measure the difference based on non-UTC datetimes,
the results would
Date math, and in particular date math + DST + leap seconds, are now
officially the bane of my existence!
0.292005-06-03
[ *** BACKWARDS INCOMPATIBILITIES *** ]
- When adding/subtraction a duration with months or days that crossed
a DST change, the result was based on the local time, not
0.22 2005-05-31
- Allow id names passed to load() to contain dashes or underscores, in
order to support RFC 3066 locale names, which use dashes.
- Fix bugs when a custom locale was registered and a class parameter
was passed to register(). Patch from Yann Kerherv.
- Switched to a
On Thu, 5 May 2005, Simon Perreault wrote:
I was a bit surprised though when I noticed that DateTime::Locale::load()
doesn't accept standard RFC 3066 language tags. This is it expects
underscores while the RFC uses dashes. So 'fr-CA' doesn't work while 'fr_CA'
does.
You'll find a small patch
On Wed, 4 May 2005, Flavio S. Glock wrote:
Flavio S. Glock wrote:
I'm working on a module that translates datetime sets into SQL statements.
I'd appreciate to have your feedback on it.
Here is a preliminary version:
http://www.ipct.pucrs.br/flavio/perl/DateTime-Format-SQL-0.00_07.tar.gz
This is
On Thu, 5 May 2005, Simon Perreault wrote:
In fact, your solution is a way to move the set logic from the app to the SQL
server. I don't think it's a good idea. You might as well have the SQL server
call a procedure using DateTime::Sets directly, it would be the same
computation. Nothing is
On Thu, 28 Apr 2005, David Wheeler wrote:
On Apr 28, 2005, at 10:48 PM, Dave Rolsky wrote:
What I'd really like to see is some way to query both single events and
recurring events within a given timeframe, all in one query that returns a
sorted array of occurrences.
I haven't tried it (yet
On Fri, 29 Apr 2005, Dave Rolsky wrote:
What I'd really like to see is some way to query both single events and
recurring events within a given timeframe, all in one query that returns a
sorted array of occurrences.
Specifically, I'm interested in offering a meetup.com-alike service
through
On Fri, 29 Apr 2005, Flavio S. Glock wrote:
Dave Rolsky wrote:
Has anyone done any work on this?
Basically, I'd like to be able to store these in a way that makes queries
like all the entries for a given month reasonably efficient.
[...]
What I'd really like to see is some way to query both
Has anyone done any work on this?
Basically, I'd like to be able to store these in a way that makes queries
like all the entries for a given month reasonably efficient.
I've come up with a few thoughts:
- Store each occurrence as a separate entry, and then store the recurrence
in a separate
On Wed, 27 Apr 2005, Rick Brewer wrote:
I recall seeing someone report this as a bug not long ago. When displaying
the short time zone for Europe/London, GMT/BST is returned.
Has a fix been found and published yet? This bug affected my system this
morning.
Are you using hte latest version of
On Wed, 27 Apr 2005, Salvador Fandino wrote:
I would like to ask for permission to use the namespace DateTime::Sort::Key
for a variation of my other module Sort::Key that is able to sort objects
based on some key of type DateTime.
This looks like a handy module, but I'd think the namespace
On Tue, 26 Apr 2005, Kirrily Robert wrote:
I'm trying to use DateTime::Duration to show the difference in days, as
an integer, between two dates. For instance, the difference between
March 1st and April 2nd should be 32 days. Unfortunately if I use the
math stuff in Datetime, I end up with a
On Mon, 18 Apr 2005, Mike Bissett wrote:
If you _want_ to take over maintenance of the module, you're welcome to do
so, BTW.
Id be happy to do so if your looking to unload, though my current experience
with CPAN is limited to only using it, and with this fix the module does
pretty much what i need
On Mon, 18 Apr 2005, Mike Bissett wrote:
Id really like to upgrade my servers to 4.1 can so I get this fixed in
the distribution please, or do I have to maintain my own
DateTime::Format::MySQL ?? Thanks
Patches without tests may sometimes get ignored by lazy developers like
myself ;)
I just
On Wed, 6 Apr 2005 [EMAIL PROTECTED] wrote:
Yes - if the set has up to 200 elements (that's an internal hard limit),
DateTime::Format::ICal should do the right thing:
Why the internal hard limit? If people want to use up all their memory,
that's their problem. A warning in the docs is good,
On Wed, 6 Apr 2005 [EMAIL PROTECTED] wrote:
Why the internal hard limit? If people want to use up all their
memory, that's their problem. A warning in the docs is good, but just
giving up at an arbitrary number just makes the software less useful.
I think this can be fixed - I'll try and make
On Fri, 1 Apr 2005, Chris P Brown wrote:
As requested, I've re-run the 2 tests that failed and attached the output.
I cannot reproduce these failures. My first guess would be that somehow
the tests are being run with an older version of DateTime.pm, but newer
tests. If you have any existing
On Thu, 24 Mar 2005 [EMAIL PROTECTED] wrote:
I was wondering if DateTime has a method for converting rata die (in
particular rd seconds) to a gregorian date? I've done a bit of digging,
but I'm not finding one, only methods for going G - RD.
Do you mean rata die days expressed in seconds (X *
On Tue, 8 Mar 2005, Rick Brewer wrote:
Thanks for the input. Ron Hill and I have been working to get some install
issues on a Windows platform using ActiveState Perl resolved. The
DateTime::TimeZone module delivers JUST the functionality we need. Hard to
test if we cannot get it installed,
0.34 2005-03-11
- Some time zone short names were incorrectly being given as something
like GMT/BST, when it should have been alternating between GMT and
BST based on the daylight saving time. Reported by Tom Yandell.
- This release is based on version 2005e of the Olson database.
On Thu, 10 Mar 2005, Rick Brewer wrote:
While testing, I am experiencing an error anytime I try and convert from
America/Chicago to some other timezone on April 3rd at anytime during the
2:00 am hour (the hour we spring forward).
I am running on Windows XP using ActiveState Perl 5.8.6. Code
On Wed, 9 Mar 2005, Rick Brewer wrote:
I was able to obtain this list myself just by making use of DateTime and
DateTime::TimeZone. Code here for anyone interested:
+++
#!perl
# Generate lists of timezones sorted alphabetically and by offset
use DateTime;
use DateTime::TimeZone;
my $names =
On Wed, 9 Mar 2005, Rick Measham wrote:
Just a thought with timezone stuff .. can we look at a non-default timezone
option that behaves like M$ (I know, it's screwy!)
I envision something that only knows about the current time zones. There is
no history.
How about future changes? I assume
On Mon, 7 Mar 2005, Tom Yandell wrote:
Apologies for cross posting this. I think that this is a problem in the
data in the Olson database, but as it is a binary format it is difficult
to verify this. I have come across this problem using the DateTime perl
module (version 0.28) whose data is
On Mon, 7 Mar 2005, Rick Brewer wrote:
Just looking for input here, is anyone using DateTime::TimeZone in a
production environment right now? We have a need to convert to-and-from a
variety of time zones from Perl in a Windows environment and need to account
for Daylight Savings Time.
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 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 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--
301 - 400 of 1076 matches
Mail list logo
