Thanks for the feedback, Tim.
Since work priorities have shifted for me, I'm not going to need this module as soon
as I thought I would. Right now, I don't know when I'm going to get to it. In short,
if anyone else really wants this module and is willing to write it, don't wait around
for me
On Fri, 6 Jun 2003, Eugene van der Pijll wrote:
> The generated TimeZone modules are a bit larger than they could be. With
> the attached patch, their total size is reduced by almost 50%.
Can you resend this as a unified diff (-u)? I can't read the other kind
very easily so I can't actually figu
On Thu, 05 Jun 2003 07:06, you wrote:
> So, just what are those "various optimizations in doing time zone
> > calculations" ? OK, building indexes is fine, but can't you access
> I'm not sure what you're referring to.
Your own words;
themachine:~/src$ head DateTime-TimeZone-0.17/README
OVERV
Okay so what should a business date module be able to do?
As a first cut:
- Business day arithmetic:
- Addition
- Subtraction
- Differences (how many b. days between X and Y)
- Know about holidays
- Have settable weekend day(s)
- Know about business hours
- Way to say if a given DT
This release adds some more docs and brings the code into sync with
bleadperl.
I haven't had any reports of problems with this code yet so I expect to
send patches to p5p real soon now.
1.06 2003-06-04
- A bug in the handling of negative offsets from UTC could lead to the
return of invalid tim
I tweaked the code that is looks like this:
#include
#ifndef isfinite
# ifdef finite
#define finite isfinite
# endif
#endif
Then later I have
#ifdef isfinite
void
_normalize_seconds(self, days, secs)
I'm hoping this can work better for all systems, since there may be
systems b
On Mon, 2 Jun 2003, Dan Sully wrote:
> > > > HPUX doesn't have finite() - it has isfinite() instead.
> >
> > Not my HPUX box. I'm running 10.20 and the HP ANSI C compiler
> > I tried the make test and here is a listing of the errors
>
> Of course they would have to change it between 10.20 and 11.0
I think there might be another Win32ism at play here. At the start of the test
file, there are the following lines (with their "value" after the comment):
my $posinf = 100 ** 100 ** 100; # "1.#INF"
my $neginf = -1 * $posinf; # "-1.#INF"
my $nan = $posinf - $posinf;
[ cc'd to datetime list ]
On Wed, 4 Jun 2003, Sam Vilain wrote:
> So, just what are those "various optimizations in doing time zone
> calculations" ? OK, building indexes is fine, but can't you access
I'm not sure what you're referring to.
> the majority of the data from the installed Olson Da
On Tue, 3 Jun 2003, John Peacock wrote:
> Is anyone else having massive problems getting cvs.sourceforge.org to behave? I
> have only once in a bunch of times since yesterday been able to connect and sync
> my sandbox with the DateTime repository. Most of the time I get:
>
> > $ cvs upd -Pd
> >
Dave Rolsky wrote:
On Wed, 4 Jun 2003, John Peacock wrote:
The t/13strftime.t file has DOS line endings, which causes all tests to fail
under Cygwin. If that is corrected, then Cygwin tests completely clean.
Really? I can't see them.
Maybe it is just in the copy that Ronald Hill sent me (I am
>
>
> On Wed, 4 Jun 2003, John Peacock wrote:
>
> > The t/13strftime.t file has DOS line endings, which causes
> all tests to fail
> > under Cygwin. If that is corrected, then Cygwin tests
> completely clean.
>
> Really? I can't see them.
I think I know what went wrong. I updated my module
On Wed, 4 Jun 2003, John Peacock wrote:
> The t/13strftime.t file has DOS line endings, which causes all tests to fail
> under Cygwin. If that is corrected, then Cygwin tests completely clean.
Really? I can't see them.
> However, I am still seeing the following failures with Win32/VC++:
>
> t\
Hi John,
>
>
> And to follow up on that, it appears that POSIX used the C
> definition for
> gmtime() and it does not *explicitely* require support for
> negative time_t
> values. It appears that DEC implementated negative time_t
> support and other
> vendors added it as well (AIX 3.2.5
John Peacock wrote:
Hill, Ronald wrote:
fails horrably on windows :(
I posted this on CLPM maybe someone has something on this.
It's even documented that way now in bleadperl:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-05/msg00495.html
And to follow up on that, it appears that
Hill, Ronald wrote:
fails horrably on windows :(
I posted this on CLPM maybe someone has something on this.
It's even documented that way now in bleadperl:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-05/msg00495.html
:~(
John
--
John Peacock
Director of Information Research and
Hi John,
[snipped]
> Specifically, the first failure is this block:
>
> > {
> > my $dt = DateTime->from_epoch( epoch => -2082844800 );
> #fails here
> > is( $dt->year, 1904, 'year should be 1904' );
> > is( $dt->month, 1, 'month should be 1904' );
> > is( $dt->day, 1, 'day
The t/13strftime.t file has DOS line endings, which causes all tests to fail
under Cygwin. If that is corrected, then Cygwin tests completely clean.
However, I am still seeing the following failures with Win32/VC++:
t\04epoch.t 255 65280283 10.71% 26-28
t\20infinite.t3 768
18 matches
Mail list logo
