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. But
Dave Rolsky wrote:
[...]
Make that:
$month[ $date->month_0 ] vs. $date->month_name
$date->month returns a 1-based numbers
$date->month_0 a 0-based named
$date->month_name returns a name based on the DateTime::Language module
the $date object is holding onto.
While I like returning 1 based num
On Monday, January 13, 2003, at 10:14 PM, Dave Rolsky wrote:
I _don't_ want to discuss implementation of this. I want to talk
about the API!
Agreed; I'm making this argument specifically because I think the
proposed API is clearer.
Looking at the two alternatives, does the second really se
On Mon, Jan 13, 2003 at 01:00:54PM -0800, Yitzchak Scott-Thoennes wrote:
> On Mon, 13 Jan 2003 13:55:17 -0600 (CST), [EMAIL PROTECTED] wrote:
> >
> >> So, this sounds like something very high level, which shouldn't be
> >> considered part of the base object. But.. it is needed for really
> >> low-l
Rich Bowen wrote:
> leap seconds seem kinda arbitrary. Is that just a table that you look up
> in?
Basically, yes.
Just like leap years, but there is no rule (there is no exact
calculations
for it).
Some (rarely) days will have one 0-60 seconds minute (instead of 0-59).
See also: Date::Leapsecon
Yitzchak Scott-Thoennes wrote:
> The iCalendar spec calls this a "floating" time
> and differentiates it from a UTC time or a time w/timezone (or a date
> without a time).
It's ok, Date::Set::Timezone already has 'local time' support (now I
know
it is called 'floating')
UTC times have a timezone
Dave Rolsky wrote:
> I think the main recise for fixed-point is to avoid rounding errors and
> allow for integer math. Or maybe I'm making that up. I'm no expert on
> date math.
Ok, Date::Tie has some special code for detecting special cases of
last-digit rounding errors (turns 0.99
On Mon, Jan 13, 2003 at 09:14:25PM -0600, Dave Rolsky wrote:
> On Mon, 13 Jan 2003, Matthew Simon Cavalletto wrote:
> > Looking at the two alternatives, does the second really seem clearer?
> >
> >use DateTime;
> >my $dt = DateTime->new( 'MySQL' => $mysql_dt );
> >print $dt->to_string(
Dave Rolsky wrote:
>
> On Mon, 13 Jan 2003, fglock wrote:
> > There is a licence is in the first lines of lib/Date/Set.pm.
>
> It should be in a LICENSE file in the top-level directory.
Done.
I just sent the latest Date::Set::Timezone (0.03) to CPAN.
Now I'm working on a DateTime version.
I'll
On Tue, Jan 14, 2003 at 12:27:30AM -0600, Dave Rolsky ([EMAIL PROTECTED]) wrote:
> On Mon, 13 Jan 2003, Martijn van Beers wrote:
>
> > gives:
> > [19700329T02..19701025T03],
> > [19710328T02..19711031T03],
> > [19720326T02..19721030T03]
> >
> > The format of the
On Tue, 14 Jan 2003, Nick Tonkin wrote:
> My preference is to keep integers out of variable names. It's easier to
> read.
>
> What about $date->month_zero_indexed ?
Maybe.
> Also: What about my suggestion that a switch in the DateTime constructor
> cause the default methods to become zero-indexe
Dave Rolsky wrote:
> Anyway, go ahead and send me a tarball and I'll import it. But let's talk
> API before you go too much further. I don't want to waste your time.
Here:
http://www.ipct.pucrs.br/flavio/perl/DateTime-Set-0.00_01.tar.gz
- Flávio S. Glock
On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote:
> >> Looking at the two alternatives, does the second really seem clearer?
> >>
> >>use DateTime;
> >>my $dt = DateTime->new( 'MySQL' => $mysql_dt );
> >>print $dt->to_string( 'MySQL' );
> >>
> >>use DateTime;
> >>use DateTim
On Tue, 14 Jan 2003, srl 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 wa
On Tue, 14 Jan 2003, Martijn van Beers wrote:
> > > Looking at the two alternatives, does the second really seem clearer?
> > >
> > >use DateTime;
> > >my $dt = DateTime->new( 'MySQL' => $mysql_dt );
> > >print $dt->to_string( 'MySQL' );
> > >
> > >use DateTime;
> > >use DateTi
On Tue, 14 Jan 2003, fglock wrote:
> There is a very important thing to note, however:
> DateTime::Set stores pointers to leaves (of course).
>
> If a DateTime object is a leaf, it should never be changed,
> or it might break something:
>
> $d1 = new DateTime( some-date );
> $d2 = new DateTime
On Tue, 14 Jan 2003, Martijn van Beers wrote:
> On Tue, Jan 14, 2003 at 01:32:39PM -0200, fglock wrote:
> > > It should use DateTime as the leaf class, just like Date::Set really
> > > should use Date::ICal as the leaf class.
> >
> > Ok, I'll try to do that.
> >
> > There is a very important thing
Dave Rolsky wrote:
my $dt1 = new DateTime "Yesterday";
No, these would have to be either:
my $dt = DateTime->parse( "Yesterday" );
or
my $dt = DateTime::Parse::Extended->datetime( "Yesterday" );
So what input would use DateTime->new instead? Or are you saying that of my
examples,
Dave Rolsky wrote:
use DateTime;
use DateTime::Parse::MySQL;
my $dt = DateTime::Parse::MySQL->new_datetime( $mysql_dt );
print DateTime::Parse::MySQL->mysql_datetime( $dt );
I can also imagine some other scheme, where parse/format modules register
the formats they can handle with DateTime
On Tue, Jan 14, 2003 at 12:27:30AM -0600, Dave Rolsky wrote:
> On Mon, 13 Jan 2003, Martijn van Beers wrote:
>
> > gives:
> > [19700329T02..19701025T03],
> > [19710328T02..19711031T03],
> > [19720326T02..19721030T03]
> >
> > The format of the time strings and th
I'm going to lay out my requirements for how this will work in order to
constrain the discussion, because I really have a firm idea of how this
needs to work.
My constraints are:
1. A module should be able to choose to implement parsing, formatting, or
both. For example, if we want to add "know
On Tue, 14 Jan 2003, Martijn van Beers wrote:
> On Tue, Jan 14, 2003 at 12:27:30AM -0600, Dave Rolsky wrote:
> > On Mon, 13 Jan 2003, Martijn van Beers wrote:
> >
> > > gives:
> > > [19700329T02..19701025T03],
> > > [19710328T02..19711031T03],
> > > [19720326T02..19721030
On Tuesday, January 14, 2003, at 12:55 PM, Dave Rolsky wrote:
use DateTime;
my $dt = DateTime->new( 'MySQL' => $mysql_dt );
print $dt->to_string( 'MySQL' );
use DateTime;
use DateTime::Parse::MySQL;
my $dt = DateTime->from_mysql_datetime( $mysql_dt );
print $dt->to_mysql_st
[ hopefully this will move to the new thread I just started ... ]
On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote:
> My suggestion would be that strftime also be placed in an external
> module.
>
>package DateTime::Format::strtime;
>
>sub string_to_rdsec { ... } # strptime
>
>sub
On Tue 2003/01/14 13:16:08 CST, Dave Rolsky <[EMAIL PROTECTED]> writes:
> 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
> mo
On Tue, 14 Jan 2003, Stephen R. Wilcoxon wrote:
> > So given those constraints, here are the potential options on the table,
> > _so far_ (I welcome others that fit into the above constraints).
> >
> > use DateTime;
> > use DateTime::Parse::MySQL; # this needs a better name
> > my $dt = Date
On Tuesday, January 14, 2003, at 02:16 PM, Dave Rolsky wrote:
My constraints are:
1. A module should be able to choose to implement parsing, formatting,
or both. [...]
Definitely.
2. I really want to avoid runtime module loading. [...]
Agreed, in a mod_perl context you'll definitely be abl
Dave:
There was a bug in my tests. Here is the new version:
http://www.ipct.pucrs.br/flavio/perl/DateTime-Set-0.00_02.tar.gz
These are the news:
- Base object is DateTime.pm; there is no 'leaf' object
- The tests are NOT comprehensive, yet
- There are no changes to Date::Set::Timezone API
- D
On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote:
> > use DateTime::Parse::MySQL; # this needs a better name
>
> I've suggested "DateTime::Format::MySQL".
Actually, I'm leaning towards DateTime::Representation::* at the moment.
Format is correct if read as a noun, but confusing if read as a
On Tuesday, January 14, 2003, at 02:33 PM, Dave Rolsky wrote:
On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote:
Modules like Date::Discordian or Date::Maya, which have no internal
storage format and only exist to convert to and from other calendar
formats, could easily be refactored to follo
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( ..
Dave Rolsky wrote:
I'm going to lay out my requirements for how this will work in order to
constrain the discussion, because I really have a firm idea of how this
needs to work.
My constraints are:
1. A module should be able to choose to implement parsing, formatting, or
both.
And as you poi
On Tuesday, January 14, 2003, at 03:03 PM, Dave Rolsky wrote:
use DateTime::Parse::MySQL; # this needs a better name
I've suggested "DateTime::Format::MySQL".
Actually, I'm leaning towards DateTime::Representation::* at the
moment. Format is correct if read as a noun, but confusing if rea
On Tue 2003/01/14 16:14:51 EST, Matthew Simon Cavalletto <[EMAIL PROTECTED]
> writes:
> Representation is kind of long-winded, and I'm not sure it communicates
> the text-centric nature of the code in question, but I could live with
> it.
Agreed (Representation is longer than I'd prefer).
> Her
On Tuesday, January 14, 2003, at 01:36 PM, Stephen R. Wilcoxon wrote:
On Tue 2003/01/14 16:14:51 EST, Matthew Simon Cavalletto
<[EMAIL PROTECTED]
writes:
Representation is kind of long-winded, and I'm not sure it
communicates
the text-centric nature of the code in question, but I could live wi
On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote:
> On Tuesday, January 14, 2003, at 03:03 PM, Dave Rolsky wrote:
>
> >>> use DateTime::Parse::MySQL; # this needs a better name
> >>
> >> I've suggested "DateTime::Format::MySQL".
> >
> > Actually, I'm leaning towards DateTime::Representation
On Tuesday, January 14, 2003, at 03:26 PM, Dave Rolsky wrote:
I'm concerned that this approach may end up requiring that
DateTime::Calendar::Discordian to be a subclass of DateTime, and I
know you've recently argued that calendars that aren't Gregorian
shouldn't be subclasses of DateTime due
On Tue, 14 Jan 2003, Bruce Van Allen wrote:
> Form, Formats, Idiom, Type, Mode, Style, Trans, Translate, IO, ...
>
> Form is concise, works as noun & verb.
I think the point is that it not work as verb.
> Formats (w/ 's') doesn't have the problem Dave pointed to for Format.
That's cool.
How a
On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote:
> > You seem to be assuming that other calendars are likely to be able to
> > take advantage of DateTime.pm methods like strftime() or hour().
>
> Erm, then there's been some kind of miscommunication, because that's
> not what I was trying to sa
On Tue, 14 Jan 2003, Nick Tonkin wrote:
> On Tue, 14 Jan 2003, Bruce Van Allen wrote:
>
> > Form, Formats, Idiom, Type, Mode, Style, Trans, Translate, IO, ...
> >
> > Form is concise, works as noun & verb.
>
> I think the point is that it not work as verb.
>
> > Formats (w/ 's') doesn't have the p
On Tuesday, January 14, 2003, at 06:58 PM, Dave Rolsky wrote:
I question whether or not strftime (as used for Gregorian calendars)
will be terribly useful for other calendars, since at least some
portion of the specifiers won't translate.
Agreed, strftime per se is Gregorian-centric.
(Other
On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote:
> On Tuesday, January 14, 2003, at 06:58 PM, Dave Rolsky wrote:
>
> > I question whether or not strftime (as used for Gregorian calendars)
> > will be terribly useful for other calendars, since at least some
> > portion of the specifiers won't
On Tuesday, January 14, 2003, at 07:24 PM, Dave Rolsky wrote:
On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote:
Agreed, strftime per se is Gregorian-centric.
Ok, then what were you proposing moving out of (or not putting in)
DateTime.pm in favor of putting it in a library.
I (and others
John Peacok wrote:
> Dave Rolsky wrote:
> > 4. Given the choice between adding more parameters or more methods, I
> >prefer to add more methods, which is why I dislike
> >
> > DateTime->new( mysql => $mysql_dt )
> >
> > as opposed to
> >
> > DateTime->from_mysql_datetime( $mysql_dt )
>
> I
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 => DateTime::Format
On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote:
> Using strftime as an example, this suggests the following code:
>
>package DateTime;
>
>sub strftime { (shift)->format_string('strtime', @_) }
>
>sub format_string {
> my ($dt, $type, @fmt) = @_;
> my $package = "DateTime
47 matches
Mail list logo
