On Thu, 9 Jan 2003, Chris Josephes wrote:
2. Use the DateTime:: namespace. The [EMAIL PROTECTED] cabal doesn't
like it? That's nice. Their buy-in is nice, but lack thereof does
not prevent success. And in my experience, when presented with
working code that's being used by a bunch of
On Fri, 10 Jan 2003, Matthew Simon Cavalletto wrote:
- DateTime::Base [...] A good candidate for this is the existing
Date::ICal code, with a bunch of the Time::Piece convenience methods
thrown in for good measure.
I'd suggest having an abstract base class one level above the ICal
On Fri, 10 Jan 2003, Matt Sergeant wrote:
What I want to see is a Time::Piece based on Date::Ical (or if that becomes
DateTime.pm then fine). I've wanted that since I read the Pod for
Date::Ical and realised (like David and Dave have) that it's not just for
the ICal format - it's actually a
On Fri, 10 Jan 2003, dLux wrote:
I have checked the Date::ICal module, which addressed most of the issues
I have faced in the development of Class::Date. Although it does not
solve all of this, the module implementation is quite good, ideal for
a DateTime base class.
I think it certainly
On Fri, 10 Jan 2003, Matt Sergeant wrote:
Don't throw out the baby with the bathwater. There's some good things
going for Time::Piece right now:
1. It has a *lot* of users.
2. It has quite a bit of good and mostly reusable code.
3. It's the API blessed/designed by Larry Wall (that may or
On Fri, 10 Jan 2003, John Peacock wrote:
1. Stop herding cats. If existing module authors don't want to play,
then screw them.
One word for you: wrappers. I want to call to your attention the methodology
pursued by Tels when he rewrote the Math::BigInt/BigFloat core modules. He
On Fri, 10 Jan 2003, dLux wrote:
I disagree with this, because handling these things are not
object-dependent, but context-dependent. I need to write a function,
which handles dates in one way, but I don't want to force users of the
module work dates like this.
When I have a function, which
On Fri, 10 Jan 2003, Rich Bowen wrote:
[ CC'd to the Mpls Perl Monger list, Matt Sergeant, and David Wheeler, all
of whom have expressed some interest in the topic. I'd suggest that
further discussion be solely on the [EMAIL PROTECTED] list, however. ]
Thanks, Dave, for doing this. This
On Fri, 10 Jan 2003, Jean Forget wrote:
There *is* a difference between Date:: and Time:: namespaces. Date::
modules do not consider durations less than one day. I did not choose
at random between Date:: and Time:: for my module, neither did Rich
Bowen (Discordian), Abigail (Maya), Leo
On Fri, 10 Jan 2003, Stephen R. Wilcoxon wrote:
On Thu 2003/01/09 16:04:04 CST, Dave Rolsky [EMAIL PROTECTED] writes:
-- Provides simple date parsing ala Time::Piece-strptime. Maybe throw in
the functionality provided by Date::Parse? Maybe make this a separate
module. Doesn't matter
On Fri, 10 Jan 2003, Ken Williams wrote:
Yeah, the base module should accept several different non-ambiguous
canonical formats such as the ones used in RFCs, and things like
-MM-DD HH:MM:SS. A supplementary module could handle fuzzy stuff
like 3 days ago and a month from tomorrow.
Just
On Fri, 10 Jan 2003, David Wheeler wrote:
On Friday, January 10, 2003, at 01:17 AM, dLux wrote:
- To make it supported by the whole perl community, inclucing module
developers. For example, I want to pass a date object to the DBI
bind_param method without the need of converting it to
On Fri, 10 Jan 2003, David Wheeler wrote:
The problem with that is that then the particular $sth would have to
have the necessary column bound explicitly:
$sth-bind_param($param_num, $bind_value,
{ type = DATE_TIME });
While that'd do-able, it's annoying. I'd rather
I'm going to make a dictatorial declaration for this project.
All code used in the project _must_ be licensed under the same terms as
Perl itself.
No arguing, no weird licenses, no this software is free, I don't care
what you do with it.
K?
Good.
Now, a problem. The following modules need
So I'm starting to work on turning Date::ICal into DateTime.pm. The first
step was a global search and replace. That part went well, and I was very
proud of myself. I felt like a super-hacker ;)
Then I started added some of the simple-to-add Time::Piece methods, like
day_of_year, hms, ymd, and
[ CC'd to the Mpls Perl Monger list, Matt Sergeant, and David Wheeler, all
of whom have expressed some interest in the topic. I'd suggest that
further discussion be solely on the [EMAIL PROTECTED] list, however. ]
Ok, the state of Perl's date and time modules continues to suck. They all
have
On Thu, 9 Jan 2003, Darren Young wrote:
I've been using Perl for several years and have always HATED doing
anything with date/time information. I've avoided it whenever possible
because finding a module that will do function(x), actually works and
has up to date documentation is nearly
On Fri, 10 Jan 2003, Dave Rolsky wrote:
There's a couple of thoughts I wanted to bounce off of people before I go
too much further. Please take a look at the Time::Piece API if you're not
familiar with it.
Doh, and another thought, unrelated to Time::Piece.
What updating methods should
[ must stop replying to self like the big freak that I am ... ]
On Sat, 11 Jan 2003, Dave Rolsky wrote:
Right now, this module occasionally warns or carps about bad parameters,
and then returns undef. I'm not a big fan of warnings in modules myself.
I prefer to either simply return
On Sat, 11 Jan 2003, David Wheeler wrote:
The first option has the advantage of greatly simplifying the
internals. Once you calculate the julian day and seconds for an
object, it just never changes. The disadvantage is that the API may
seem odd to some folks. But we could still provide
[ Soon the list archives will consistent entirely of me responding to
myself ... ]
On Sat, 11 Jan 2003, Dave Rolsky wrote:
On Sat, 11 Jan 2003, Rich Bowen wrote:
On Fri, 10 Jan 2003, Dave Rolsky wrote:
Can we simply declare 0-based as the standard for day of week and day of
year
On Sat, 11 Jan 2003, Rich Bowen wrote:
On Fri, 10 Jan 2003, Dave Rolsky wrote:
Can we simply declare 0-based as the standard for day of week and day of
year, and 1-based for day of month, month of year, and week of year.
FWIW, that's what Date::ICal already had implemented, I believe
On Sat, 11 Jan 2003, Matthew Simon Cavalletto wrote:
Hmm -- that looks like trouble; month_name() is the written version of
month(), but day_name() is the written version of day_of_week() rather
than of day().
But days only have names in terms of their position in the week. Unless
you call
On Sun, 12 Jan 2003, David Wheeler wrote:
On Sunday, January 12, 2003, at 11:15 AM, John Peacock wrote:
A lot of the 0-based vs 1-based arguments should be resolved simply by
having our interface design in place. Programmers will be less
inclined to have to look up some 0-based array
On Sun, 12 Jan 2003, Matthew Simon Cavalletto wrote:
Ick. That's clearly not as nice as just saying $dt-hour(17).
Whether this method is an updater is an entirely different can of worms ;)
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
On Sun, 12 Jan 2003, David Wheeler wrote:
So keep the base class named DateTime and provide a single
implementation class module DateTime::Gregorian, which is the default
unless you ask for something else. The advantage of this is we have
to work through the interface issues required to
On Sun, 12 Jan 2003, dLux wrote:
# same as $old_date but day of month is 5
my $new_date = $old_date-clone( day = 5 );
I used this in Class::Date, because of the object-semantics of perl:
If an object is referenced from more than one place, then it silently
changes all date
On Sun, 12 Jan 2003, David Wheeler wrote:
John and I liked the former option, though you expressed your
opposition to it yesterday. The advantage is that the interface is
exactly the same regardless of calendaring system, and we deal with the
issues of allowing DateTime to return different
On Sun, 12 Jan 2003, Nick Tonkin wrote:
Reality is that while a good interface will go a long way towards that
goal, there will be a lot of users of the objects that will expect
zero-indexed values for a lot of fields for a variety of reasons. And if
you want the module to be really useful
On Sun, 12 Jan 2003, David Wheeler wrote:
On Sunday, January 12, 2003, at 02:33 PM, Dave Rolsky wrote:
I think throwing an object is better. I don't really like parsing
error messages to determine what error is happened. Just think about
internationalization.
I think we've agreed
On Sun, 12 Jan 2003, Yitzchak Scott-Thoennes wrote:
Date::ICal uses what Calendrical Calculations uses (that they call
Rata Die, fixed date). They are days on or after Jan 1 of year 1
(Gregorian). This different from MJD. I'd like to see Date::ICal
switch to using rd to describe them
On Sun, 12 Jan 2003, Matthew Simon Cavalletto wrote:
# Our core calendar
DateTime::Gregorian-- Our primary, modern calendar
DateTime::Gregorian::Language -- Internationalization
DateTime::Gregorian::RichParser - Based on Date::Manip et al.
Except as you point out,
On Sun, 12 Jan 2003, Matthew Simon Cavalletto wrote:
I was originally unenthusiastic about static date-time objects, but
then I realized that it'd be reasonably straightforward to build a
variable wrapper object, which could then be used to hold a series of
static objects:
Ack, too much
On Mon, 13 Jan 2003, Rich Bowen wrote:
It's an interesting point in this case, with this being one of the very
few calendars that changes how time is handled. However, since the
purpose of the module in question is conversion between Gregorian and
French Revolutionary, I would expect that it
On Mon, 13 Jan 2003, Matthew Simon Cavalletto wrote:
What's the benefit of making this distinction between core and other
formats?
Because core parsing would be available simply by doing:
use DateTime;
That's about it.
Why not define a parser interface and include the basic formats as
On Mon, 13 Jan 2003, Rich Bowen wrote:
We had discussed, at some length, over on Reefknot, about making these
things storable, and that's an ongoing consideration. Putting an object
in the object is all well and good, as long as there is a simple
strinification that we can do, and store in a
On Mon, 13 Jan 2003, Martijn van Beers wrote:
But nothing fancy, just a few formats should be supported in the
base class, including epoch time, ICal, and maybe ISO 8601.
I wouldn't call epoch arguments parsing, but I would really like it if
this wasn't in the base class. Making people go
Monday!
How exciting. I figured I might as well just pick something, and so I
picked Monday. There were a lot of excellent candidates, and Friday's
performance was excellent, but overall Monday best exemplified the
qualities that I look for in a week-starter.
-dave
/*===
On Mon, 13 Jan 2003, Martijn van Beers wrote:
gives:
[19700329T02..19701025T03],
[19710328T02..19711031T03],
[19720326T02..19721030T03]
The format of the time strings and the recurrence rules are defined
in the iCalendar rfc (2445). This was used
We need to handle them. Flavio claims that using floating point seconds
makes this easier.
I have an idea on how to handle it without that, but I'd like to hear
Flavio's idea. And if anyone else has any good ideas or pointers to known
implementations (I know libtai64 handles it, for one),
On Mon, 13 Jan 2003, Martijn van Beers wrote:
On Mon, Jan 13, 2003 at 01:58:59PM -0600, Dave Rolsky wrote:
I agree that epoch is bad, because it's so limited, but it's a standard
that a lot of people are familiar with, so it needs to be supported in the
core object.
That is exactly why
Anyone want to tell me what the %E* modifier is supposed to do for
stftime?
And do we need it? How about the %O* modifier? Is implementing that
important?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
For those who care, CVS checkin diffs are sent to the
[EMAIL PROTECTED] list (sign up via sourceforge).
For now, I don't want to really discuss anything on that list, because the
project hasn't really gotten to the point where only a core group of
developers should discuss development issues.
On Tue, 14 Jan 2003, Jonathan Scott Duff wrote:
I was thinking that a sort of DBI/DBD dichotomy could be applied to
DateTimes but along multiple dimensions. Something like this:
my $dt = DateTime(
parser = DateTime::Parser::MySQL,
formatter =
Just as an FYI for all datetime implementors.
-- Forwarded message --
Date: 15 Jan 2003 21:56:36 +0100
From: Claus Tondering [EMAIL PROTECTED]
To: Dave Rolsky [EMAIL PROTECTED]
Subject: Re: Copyright on algorithms in FAQ
Hi Dave,
You wrote:
So we need to know if you're
On Wed, 15 Jan 2003, srl wrote:
Rich Bowen emailed them at one point and got an agreement from them
that he could implement the algorithms and release the code freely,
as long as he let them publish the code in the next version of the
book. Last I heard, he was confirming that understanding
On Wed, 15 Jan 2003, Jonathan Scott Duff wrote:
I agree, but you forgot step 0: Ask the authors if they'd be willing
to release the code under an open source license. It doesn't hurt to
ask and if they refuse, then we just continue ignoring the book for
implementation advice.
I did mention
On Thu, 16 Jan 2003, Ilmari Karonen wrote:
module ends up being loaded once per child process. See
http://perl.apache.org/docs/1.0/guide/performance.html#Preloading_Perl_Modules_at_Server_Startup
for an explanation of why this is important.
This doesn't necessarily rule out the -new(
On Tue, 14 Jan 2003, Martijn van Beers wrote:
Actually, I recently discovered that Date::ICal _does_ support this. if
you do $date-ical (localtime = 1) it prints the time adjusted for
the local timezone.
Floating time *still* has a timezone. It is just variable. But, since
your computer can
On Thu, 16 Jan 2003, Nick Tonkin wrote:
Umm, improper grammar caused by hasty response caused by a teensy-weensy
overdose of hubris? Everyone is in awe of your commitment and energy, Dave
... sometimes you're becoming a bit short with folks, though ...
Sorry. I get frustrated when people
On Thu, 16 Jan 2003, Jean Forget wrote:
I discovered about %E* and %O* in AIX's date(1) manpage. Nothing about that in
Linux's
date manpage. The basic specifiers are pretty much consistently defined,
but not so for %E* and %O*. And maybe I inadvertently swapped %EY and %OY about Roman
On Thu, 16 Jan 2003, John Peacock wrote:
I've been thinking about the API for parsers and storage methods and I have a
different suggestion than what has been discussed before. The current model
seems to assume that there is a single DateTime object type, regardless of
backend storage
It looks like its back. For how long, who knows? ;)
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Fri, 17 Jan 2003, Adam Turoff wrote:
On Thu, Jan 16, 2003 at 03:40:57PM -0600, Dave Rolsky wrote:
- Point out that at least some portion of this code is _already_ Free
Software. See
http://savannah.gnu.org/cgi-bin/viewcvs/emacs/emacs/lisp/calendar/
If this is the case, then why
On Fri, 17 Jan 2003, John Peacock wrote:
my $formatter =
DateTime::Formats::ISO8601-new
( class = 'DateTime::Implementation::TAI64' );
my $dt = $formatter-parse( ... );
That's OK, but too verbose for the average user, IMHO. It also leaps too deeply
into the API
On Sun, 19 Jan 2003, Rich Bowen wrote:
I presume this is actually intentional:
t/03componentsok 19/44Can't locate object method ical via package
DateTime at t/03components.t line 36.
If so, could you please remove the tests that require this method, so
that we can have a passing test
On Sun, 19 Jan 2003, John Siracusa wrote:
That's a nice idea, but people may want to use these modules without using
DBI
And so they can. What's stopping them?
Nothing. I'm just saying that the API needs to work both for standalone
use and for use by the DBI modules.
and I have no
On Sun, 19 Jan 2003, John Siracusa wrote:
Okay, but my point was that standalone use of db-specific date formatting
and parsing (i.e. in the absence of a $dbh) will be very rare (assuming we
do get it hooked into DBI as proposed). So while it should still certainly
be possible, don't spend
On Sun, 19 Jan 2003, Nick Tonkin wrote:
I'm with John on this. I think the earlier this is designed in, the
better. And I know Tim, a friend and former employee, would agree.
That's cool. Seeing as this isn't a super-important feature for me, and
my plate is reasonably well packed, I'd be
On Fri, 24 Jan 2003, Peter J. Acklam wrote:
I believe this thread proves that what is considered the first day
of the week must be customizable. If it isn't, then someone
(perhaps not someone on this mailing list, but someone) will be
dissatisfied and consider the DateTime modules useless
On Fri, 24 Jan 2003, Clayton L. Scott wrote:
So if I want to use Sunday as the first day of the week every will
method I use will have sunday in it? What if for some business reason
I decide that it's easier to do my calculations if Wednesday is the first
day of the week?
How about:
use
So I'm hacking away at time zone code and getting darn close to producing
something usable, dare I even say elegant? We'll see on both counts, I
suppose ;)
Anyway, I've been working with the raw Olson DB the last couple days, and
I've produced a parser that can read its rules, zones, links and
I just checked in a lot of new/changed code under
modules/DateTime-TimeZone. This code actually seems to work, and provides
access to the complete Olson historical data, plus ongoing time zone
changes in the future.
I'd realy appreciate some code review on this, even though it's still a
bit
On Tue, 28 Jan 2003, Peter J. Acklam wrote:
[...] the fact that an ISO date can be expressed 6 different
ways, which makes ISO less attractive to me.
I don't see why this is relevant. A date may be represented in
many more than six ways, but as long as one picks one format and
everyone
On Tue, 28 Jan 2003, Eugene van der Pijll wrote:
On the other hand, I would like to be able to specify a date with a
precision of less than a day. For example, the date 1815, or
july 1974. But I'll write my own module around DateTime that can
handle these dates, if necessary.
You'll probably
On Mon, 27 Jan 2003, John Peacock wrote:
Hence, it would seem to me to make the most sense to store the basic DateTime
object as an array of (possibly undefined) periods: years, months, days, hours,
minutes, seconds, etc. By doing it this way, instead of some sort of days since
some epoch,
On Tue, 28 Jan 2003, John Peacock wrote:
Tell you what; I'll write an implementation of my way (probably in XS) and we'll
compare. I think you're mistaken; your storage methods requires conversion for
all nontrivial operations (e.g. $dt-year), whereas mine only needs a conversion
when
On Tue, 28 Jan 2003, Peter J. Acklam wrote:
I searched the archives and read a whole lot of postings, but
didn't find anything about what I wrote, so that's why I posted
it.
I wanted to join this project and contribute something, but first
I wanted to understand the reason behind some of
On Tue, 28 Jan 2003, John Peacock wrote:
Dave Rolsky wrote:
Well, an XS implementation is quite likely to beat pure Perl, even if you
used RD days as well.
Don't tell anyone, but my first pass will be pure Perl, since I am still pretty
much an XS newbie...
Hehe, that's fine. My guess
On Tue, 28 Jan 2003, John Peacock wrote:
Hehe, that's fine. My guess is that this is probably a much easier way to
write an XS module, since all you'll have to do is re-implement the same
logic in C, which leaves you free to _only_ think about all the low-level
C crap you have to deal
On Fri, 31 Jan 2003, John Peacock wrote:
Let me think out loud now. If we are always storing time _and_ TZ, then it
certainly make more sense to me to use UTC to store the time. How's this for a
good example (pseudo-code):
my $t1 = new DateTime::Simple (2002-12-30T08:00:00, TZ =
In fixing the brokenness of the time zone code, I've come across what
appears to be an insoluble problem.
We want to allow people to create a DateTime object based on their _local_
time. Internally, we want to have UTC time available, so we need to know
the offset for a given local time. This
This hostname now exists and I can put stuff on it, including dynamic
content (with mod_perl and preferable, Mason).
Submissions for content are welcome. Some things I'd like to put up
there:
- info about existing modules
- developer docs for DateTime project
- useful links (Olson DB,
If I have a datetime object with a floating time zone and then I set the
time zone to some non-floating zone, I shouldn't change the local time,
right?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Sun, 2 Feb 2003, Dave Rolsky wrote:
If I have a datetime object with a floating time zone and then I set the
time zone to some non-floating zone, I shouldn't change the local time,
right?
And how about non-floating = floating? Same thing, no adjustment, right?
-dave
On Mon, 3 Feb 2003 [EMAIL PROTECTED] wrote:
There is something else to consider. What does a timestamp of May 5,
1776, 4:16:23 PM actually _mean_? For May 5, 1976, 4:16:23 PM,
it's clear which point in time we mean when we have the timezone.
But for dates 200 years ago, it isn't so clear.
On Wed, 5 Feb 2003, Rick Measham wrote:
POD The behavior of this module when given parameters outside proper
POD boundaries (like a minute parameter of 72) is not defined, though
POD future versions may be die.
I'd prefer the behavior of:
my $dt = DateTime-new( hour = 7, minute = 75);
to
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
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
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
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
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
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
Just a few quick fixes:
- Fixed the problem running the 01load.t test seen with some versions of
Test::More. Reported by John Peacock.
- The generated modules no longer contain any POD, since that really
doesn't serve any useful purpose, and just wastes disk space.
-dave
On Fri, 7 Feb 2003, Rick Measham wrote:
A while back Dave asked us about timezones and should setting a timezone
move the internal representation or the external. We all agreed on the
external. Mainly because we couldn't think of a use for internal. Well, for
the first time ever, I'm using
On Wed, 12 Feb 2003, Peter J. Acklam wrote:
On your other point: I think it would be nice if DateTime::new
would accept years like '1974AD', '44BC, '2003CE' and '753BCE'.
But most people would say the year -753 meant 753 BC, so I would
keep that definition.
This implies that someone
On Wed, 12 Feb 2003, Eugene van der Pijll wrote:
By the way, how do you know
what the standard requires if you haven't read it? ;-)
I trust you completely. Unfortunately, ISO 8601 isn't avaliable online,
and none of the summaries I've read contain the expanded format.
You can get the
On Thu, 13 Feb 2003, Rick Measham wrote:
On 13/2/03 9:05 am, Dave Rolsky at [EMAIL PROTECTED] spake thus:
This is why there will be a DateTime::Format::ISO8601 module for parsing
ISO formats ;)
Dave, having worked with the DateTime::Format::iCal module, and with its
innards, I wonder
On Thu, 13 Feb 2003 [EMAIL PROTECTED] wrote:
b. pass the $p{name} to OffsetOnly-new() instead of $offset (and force
$offest to be calculated twice)
That's what I'll do. But it won't force offset to be calculated twice,
actually.
-dave
/*===
House Absolute Consulting
On Thu, 13 Feb 2003 [EMAIL PROTECTED] wrote:
There is a minor bug in offset_as_string, when calculating the offset for
negative timezones.
If you pass in the timezone -05:00, offset_as_string returns -19:00 this
is because, according to Perl, -5%24 == 19.
the solution is to change $hours
On Thu, 13 Feb 2003 [EMAIL PROTECTED] wrote:
A minor feature enhancement that would be great is support for the
standard timezone 'Z' which is an alias for UTC. It is frequently used
both in the ICal spec, and in the W3CDTF profile[1] which is the standard
time format for RSS.
That makes
On Thu, 13 Feb 2003 [EMAIL PROTECTED] wrote:
Btw, as should be obvious from the last couple of emails, I spent the
evening plaing with DateTime, and I've very impressed. Thought I should
mention that as I send in a slew of bug reports.
Currently epoch() on DateTime.pm calculates the epoch
On Thu, 13 Feb 2003, Eric Cholet wrote:
I want to use the DateTime language stuff, mainly so that I can use
DateTime's strftime instead of my own cooked up one, but I find it
difficult to integrate with my applications because of the non standard
English language names it uses, instead of ISO
On Thu, 13 Feb 2003, Eric Cholet wrote:
I want to use the DateTime language stuff, mainly so that I can
use DateTime's strftime instead of my own cooked up one, but I
find it difficult to integrate with my applications because of
the non standard English language names it uses, instead of
On Fri, 14 Feb 2003, Eugene van der Pijll wrote:
It seems you're right; at least, most references on the internet agree.
And as we all know, the internet can't be wrong.
The only thing more reliable than the net is The Weekly World News.
But this leads to this question: should DateTime use
On Fri, 14 Feb 2003, Lawrence K. Hixson wrote:
Astronomers (and their astronomical almanacs) recognize year zero (0
B.C.) as valid while Historians use 1 B.C. for zero since there was no
zero (0) in the Roman counting numbers (Julian Calendar!) therefore the
day before 0001-01-01 AD is
On Fri, 14 Feb 2003, Joshua Hoblitt wrote:
I've started reimplementing some of the core math in XS. If people want
to review the C code and tell me how it sucks, that'd be cool ;)
Are you planning on requiring XS for DT or also maintaining a pure Perl
implementation?
Good question. I
On Fri, 14 Feb 2003, Matthew Simon Cavalletto wrote:
However, using classes enables inheritance and other useful programming
techniques, and there's a lot to be said for that.
Good point.
Hmm. It seems like we can get the best of both worlds if we simply
allow these functions to be called
On Sat, 15 Feb 2003, John Peacock wrote:
Is there any chance you would consider something other than RedBlack trees for
the individual TZ files? The reason I ask is we could choose some algorithm
that was faster for searching than RedBlack trees as long as we make some
assumptions about the
On Sat, 15 Feb 2003, kellan wrote:
You don't think that will cut into broad acceptance? I think ideally
DateTime could be treated as a base Perl data type, but I worry about
module authors adopting it for internal use if it adds an XS dependency.
At least until DT ships in the core.
I'm not
1 - 100 of 1076 matches
Mail list logo
