On Wed, Jan 15, 2003 at 12:25:34AM +0200, Antonios Christofides wrote:
David Wheeler wrote:
It also means that users have to memorize all of the arcane strftime
formatting characters. I don't know them all, and I use stftime all
the time.
This is because strftime's format specifiers
On Tuesday, January 14, 2003, at 02:24 PM, Antonios Christofides wrote:
Dave Rolsky wrote:
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
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, Jan 15, 2003 at 02:43:57PM -0600, Dave Rolsky wrote:
Because of this, I think we need to take the following steps:
1. No implementation should explicitly use algorithms from CC.
2. No discussion of implementation matters should refer to Calendrical
Calculations. For example, don't
Abigail wrote:
I don't think you quoted the part where they put a restriction on the
algorithms (which, AFAIK, are not copyrightable or patentable; they
fall in the same categories as ideas, which can't be copyrighted either).
Ummm, at least in the US, algorythms _can_ be patented. See GIF
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 Wed, 15 Jan 2003, Dave Rolsky wrote:
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
On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote:
OK, that'll let us parse a Discordian date and format it as a
Gregorian; I assume that to print something in Discordian format we'd
use:
my $disc = DateTime::Calendar::Discordian-new( object = $dt );
print $disc-strftime( ... )
On Wed, Jan 15, 2003 at 03:34:32PM -0600, Dave Rolsky wrote:
Another side note on recurrence: we will allow people to specify
recurring datetime generators via callbacks. For what I hope are obvious
reasons, callbacks will have to guarantee that given a datetime X, they
always
On Tue, 14 Jan 2003, Dave Rolsky wrote:
2. I really want to avoid runtime module loading. This is because I have
a mod_perl bias, and with mod_perl, it's much better to load modules at
compile time (in the parent Apache process) than at runtime, where the
module ends up being loaded once
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 Wed, 15 Jan 2003, Jean Forget wrote:
Who needs %E* and %O* modifiers?
I need them. The traditional way to write a FR year is to use Roman
numerals. So, while %Y gives you the Indian-Arabian numerals (2003),
%EY gives you the Roman numerals (MMIII). At the same time, while
%j gives you
14 matches
Mail list logo
