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 met
> > > - added strftime (which may move to a separate module, but it works)
> >
> > Just out of curiosity does this add a dependence on POSIX.pm?
>
> No. It's a pure Perl implementation loosely based on Graham Barr's in
> Date::Format.
Sounds good - now if SF was only working...
Not that most people can see it with anonymous and web CVS down on SF, but
there's been some activity lately. First, I checked in the first stab at
DateTime::Formats::ICal, as well as removing all the ICal stuff from the
DateTime.pm tests and core code.
Second, I added a new top-level module docs
Dave Rolsky wrote:
> Oooh, we'll use Quantum::Superpositions! Hehe, that should satisfy
> everybody.
:)
This is _the_ authoritative site on leap seconds:
http://hpiers.obspm.fr
UT1 is the time scale based on the observation of the Earth's rotation.
UTC is derived from UT1 by adding leap sec
On Thu, 16 Jan 2003, Dave Rolsky wrote:
>
[moved here from below:]
> No, they don't. I was responding to _other_ suggestions! I don't think
> you've read the whole thread.
I did indeed read the entire thread. But as my mailreader doesn't
really do threading, I may have become confused while d
Dave Rolsky wrote:
> I should also point out I'm moving the ical-specific bits to
> DateTime::Formats::ICal.
As soon as SF gets their servers back in operation (what's up with that?), I'll
take a look at what you have. My quicky module is not meant to be an example of
anything practical, just som
On Fri, 17 Jan 2003, Ilmari Karonen wrote:
> I did indeed read the entire thread. But as my mailreader doesn't
> really do threading, I may have become confused while doing so and
> perhaps picked the wrong message to respond to. I apologize if this is
> indeed the case.
And I'm sorry for being
It looks like its back. For how long, who knows? ;)
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 16 Jan 2003, Dave Rolsky wrote:
> On Thu, 16 Jan 2003, Rich Bowen wrote:
>
> > All points noted and agreed. However, it still makes sense to ask
> > nicely. I have no interest in making enemies of these gentlemen if it is
> > not necessary.
F
On Thu, Jan 16, 2003 at 05:06:01PM -0500, Rich Bowen wrote:
> On Thu, 16 Jan 2003, Rich Bowen wrote:
> > It would be advantageous from our pint of view to have the Perl version, so
> > we'd be happy to make similar arrangements. We do expect that the Perl
> > translation would be a full translatio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
On Fri, Jan 17, 2003 at 02:55:52PM -0500, Rich Bowen wrote:
> On Fri, 17 Jan 2003, Adam Turoff wrote:
> > If this is the case, then why not just use the elisp code as a guide
> > and reimplement the interesting bits in a perlish manner? CC can serve
> > as a body of external documentation on how t
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 w
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
14 matches
Mail list logo
