>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
>>
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 compu
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
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 on
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
On Wed, 15 Jan 2003, Jonathan Scott Duff wrote:
> Oh, I guess I was misunderstanding you. After reading again, I think
> you're saying that the generators should generate strictly increasing or
> strictly decreasing datetimes.
Exactly.
> > The callbacks will work like this:
> >
> > sub generat
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
> > > al
>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->strf
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
> > boo
On Wed, 15 Jan 2003, Jonathan Scott Duff wrote:
> On Wed, Jan 15, 2003 at 01:20:48PM -0600, Dave Rolsky wrote:
> > - iterate over sorted members. Again, this is not a set operation, but
> > for convenience we will offer something like
> >
> > while ( my $dt = $dt_set->next( sort => 'asc' ) )
A
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 ment
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 understandin
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 pat
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,
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 asse
On Wed, Jan 15, 2003 at 09:56:50PM +0100, Abigail ([EMAIL PROTECTED]) wrote:
> On Wed, Jan 15, 2003 at 02:43:57PM -0600, Dave Rolsky wrote:
> >
> > Then it says "The Authors' public service intent is more than liberal
> > than suggested by the License below ...", and goes on to explicitly
> > ment
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 be
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 s
On Tue, Jan 14, 2003 at 10:49:29PM -0600, Dave Rolsky wrote:
> The other syntax you propose isn't that bad, but how does it scale when
> you want to have multiple parsers and formatters A) as defaults; and B)
> per object?
I was thinking that there would be parsedate() and formatdate()
methods tha
Dave Rolsky wrote:
[...]
MySQL has quite a number of possible formats, including:
DATETIME column - "-MM-DD HH:MM:SS"
DATE column - "-MM-DD"
TIME column - "HH:MM::S"
TIMESPAN column - "MMDDHHMMSS" and about 6-7 others
Forgive my ignorance here, but does a MySQL times
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 suck. And since the module
is brand new with a brand new interface, aiming to
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 exemplified the
>qualities that I look for in a week-starter.
>
(rofl)
Dave Rolsky wrote:
> I think the fundamental problem is that you don't have a good
> sense of what a user-friendly API would look like
That's why _you_ are in the project.
No, I don't think the problem is API or documentation.
The problem is that people don't get what a 'set' is.
We can't change
23 matches
Mail list logo
