The date still corresponds to an actual day. If I set it to Feb 31, I
should get back Mar 2 or 3 depending on the year. While I'm having
trouble thinking of a good specific example, it's a capability I've
taken advantage of many times, in holiday calculations, calendar
conversions, and such. I b
Am 09.04.2010 13:34, schrieb Mark J. Reed:
The date still corresponds to an actual day. If I set it to Feb 31, I
should get back Mar 2 or 3 depending on the year. While I'm having
trouble thinking of a good specific example, it's a capability I've
taken advantage of many times, in holiday cal
On Thu, 8 Apr 2010, Carl Mäsak wrote:
I do want to explicitly credit Dave Rolsky, whose work on the DateTime
family of modules on CPAN has informed much of the current spec,
sometimes to the point of verbatim copying.
Thanks, but I'd hate to see you copy all my mistakes too!
One thing I think
On 4/9/2010 4:53 AM, Moritz Lenz wrote:
Am 09.04.2010 13:34, schrieb Mark J. Reed:
The date still corresponds to an actual day. If I set it to Feb 31, I
should get back Mar 2 or 3 depending on the year. While I'm having
trouble thinking of a good specific example, it's a capability I've
taken ad
Am 09.04.2010 15:33, schrieb Dave Rolsky:
On Thu, 8 Apr 2010, Carl Mäsak wrote:
I do want to explicitly credit Dave Rolsky, whose work on the DateTime
family of modules on CPAN has informed much of the current spec,
sometimes to the point of verbatim copying.
Thanks, but I'd hate to see you c
On Thu, Apr 8, 2010 at 7:26 PM, Mark J. Reed wrote:
> I think that :to should stay as-is; it truncates to whatever the .week
> method returns, and that's Monday-based. It would be too inconsistent for it
> to do anything else. Asking for the latest prior Sunday or any other
> weekday is a useful
Especially since we're not ignoring leap seconds; in UTC, "30 days" is
not always 30*86400 atomic seconds. Other units are more obviously
variable-length, but you have to be careful. If you increment one
month at a time with autocorrect, 4 months from Jan 31 gets you Jun 2
or 3 instead of May 31.
Dave Rolsky wrote:
On a smaller point, I think second vs whole_second is the wrong Huffman
coding. I'd think most people want the integer value.
Well, whatever you call things, the most important thing is to keep the seconds
count as a single number which can do fractions, or if you really mus
Darren Duncan wrote:
Dave Rolsky wrote:
On a smaller point, I think second vs whole_second is the wrong
Huffman coding. I'd think most people want the integer value.
Well, whatever you call things, the most important thing is to keep
the seconds count as a single number which can do fractions
Jonathan Worthington wrote:
Darren Duncan wrote:
Dave Rolsky wrote:
On a smaller point, I think second vs whole_second is the wrong
Huffman coding. I'd think most people want the integer value.
Well, whatever you call things, the most important thing is to keep
the seconds count as a single
On Fri, Apr 9, 2010 at 3:06 PM, Jonathan Worthington wrote:
> Though even clearer and same number of characters as whole_seconds is:
>
> $dt.seconds.round
This makes more sense to me than the first example you listed because when
dealing with time measurement, I rarely think of seconds that ar
On Thu, 8 Apr 2010, Carl Mäsak wrote:
We (mberends and masak) just pushed a commit to S32::Temporal which
completely replaces what we had before. The changes are rooted in
hours of discussion on #perl6, and we feel rather more confident with
what we have now than with what we had before.
That s
Forgive me if this is a question the reveals how poorly I've been
following Perl 6 development, but what's the deal with some methods
using hyphen-separated words (e.g., day-of-week) while others use
"normal" Perl method names (e.g., set_second)?
-John
John Siracusa wrote:
Forgive me if this is a question the reveals how poorly I've been
following Perl 6 development, but what's the deal with some methods
using hyphen-separated words (e.g., day-of-week) while others use
"normal" Perl method names (e.g., set_second)?
There are 2 answers to that
14 matches
Mail list logo
