On Wed, 2 Apr 2003, Flavio S. Glock wrote:
> Dave, is this syntax ok?
>
> @datetimes = $set->as_list( span => $this_year );
>
> - "span" is optional, if the set is bounded.
> - otherwise, the program dies.
Hmm ...
what exactly is span? A DateTime::Span? If not, I don't think we should
use th
On Wed, 2 Apr 2003, Flavio S. Glock wrote:
> +1 it makes the program simpler
> +1 we can implement "as_list" in the DT::Set module if people find it
> useful.
> -1 However, it forces people to install DT::Set.
>
> +1 :)
I think DT::Set will be needed by so many different other DateTime m
> > I got a copy of Calendrical Calculations yesterday and have just about
> > finished the Mayan/Long count calendar. Should the Haab and Tzolkin
> > calendars be in the same module (ick!)
>
> I'd think so. You can't really have a separate Haab calendar, as a Haab
> date contains only "month" and
Dave, is this syntax ok?
@datetimes = $set->as_list( span => $this_year );
- "span" is optional, if the set is bounded.
- otherwise, the program dies.
Hill, Ronald wrote:
> > +1 we can implement "as_list" in the DT::Set module if people find it
> > useful.
>
> yes!
> I for one think this wo
[snipped]
>
> >Hill, Ronald wrote:
> > I have just completed some documentation on the sunrise module
> > and I still have the as_list method (which does not work
> >correctly). I was going to remove this
> > since we have the sunrise_as_set & sunset_as_set methodes
> >which does the same thing
Hill, Ronald wrote:
> I have just completed some documentation on the sunrise module
> and I still have the as_list method (which does not work correctly). I was
> going to remove this
> since we have the sunrise_as_set & sunset_as_set methodes which does the
> same thing.
I agree.
+1 it makes
Hi Flavio,
>
> Daisuke Maki wrote:
> > Then I realized that that was dependent on the time of sunrise and
> > sundown, so I took my half-assed implementation out of that
> module. If
> > you know how that could be done, that would be cool.
>
> DateTime::Event::Sunrise is already usable. It can
Daisuke Maki wrote:
> Then I realized that that was dependent on the time of sunrise and
> sundown, so I took my half-assed implementation out of that module. If
> you know how that could be done, that would be cool.
DateTime::Event::Sunrise is already usable. It can give you the
time of sunrise a
Since I now know you're in this list as well, here's something I could
use some input ;)
Originally, I was going to make DT::Format::Japanese be able to return
values in the "Eto" format, like 3:00 am being "Ushi-Mitsu-doki".
Then I realized that that was dependent on the time of sunrise and
s
Dave Rolsky schreef:
> On Wed, 2 Apr 2003, Jean Forget wrote:
> > For the moment, there are two sets of accessors:
> > - hour, min, second, etc for sexagesimal time
> > - dhour, dmin and dsecond for decimal time
IMHO, this is the way to go.
> > but strftime knows only decimal time.
I think it sh
Joshua Hoblitt schreef:
> I got a copy of Calendrical Calculations yesterday and have just about
> finished the Mayan/Long count calendar. Should the Haab and Tzolkin
> calendars be in the same module (ick!)
I'd think so. You can't really have a separate Haab calendar, as a Haab
date contains onl
Well, what you made works, but I think it's somewhat missing the point.
Yeah, I had that nagging feeling all along ;)
good thing you took a look.
But your object does not actually represent the Japanese calendar. What
I'm getting at is that given a DateTime::Calendar::Japanese object, I'd
expect
On Wed, 2 Apr 2003, Flavio S. Glock wrote:
> Some random thoughts (not necessarily my opinions):
>
> - we'd rather have Right than Stable.
For now, at least, yes. Later, no. For example, I'd consider the
DateTime.pm API pretty stable at this point, since other people are
already using it for th
I need some guidelines regarding how to deal with API changes
(such as removing the "new" method).
I think those guidelines should become part of the
"development-standards".
Some random thoughts (not necessarily my opinions):
- we'd rather have Right than Stable.
- people _know_ the modules ar
Brad Hughes wrote:
> But DT::Calendar::X now means the *form* of date calendar X, not the set of
> days themselves and other information about that set of days that make up a
> calendar, like start time and end time for the NYSE calendar (yes, potentially
> different for different days).
I think
> On Tue, 1 Apr 2003, Flavio S. Glock wrote:
> > It looks like a work for "DateTime::Event::Builder"
What about a DateTime::Event::ICal module?
There is some code in Date::Set we could use...
- Flavio S. Glock
Dave Rolsky wrote:
On Tue, 1 Apr 2003, Jonathan Leffler wrote:
[...]
Nomenclature is important, isn't it?
Oh yes. It's one of my obsessions, as some on this list may have already
guessed.
One of them most important (perhaps #1) aspects of code design is proper
naming. This applies to both interna
At Tue, 01 Apr 2003 17:31:06 -0800,
Daisuke Maki wrote:
>
> I've hacked together DT::Calendar::Japanese and DT::Format::Japanese. Is
> there anybody on this list that can use Japanese on his machine?
Here, here ;-)
I'd love to look into these modules in this weekend, hopefully.
> Features:
>
On Tue, 1 Apr 2003, Daisuke Maki wrote:
> DT::Format::Japanese:
> - support kanji, zenkaku arabic, and ascii arabic numbers
> - support eras
BTW, this one looks great.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Tue, 1 Apr 2003, Daisuke Maki wrote:
> I've hacked together DT::Calendar::Japanese and DT::Format::Japanese. Is
> there anybody on this list that can use Japanese on his machine?
I somehow got emacs to do so, yes. If it's working and displaying the
right characters, then my pathetic character
20 matches
Mail list logo
