| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
to a char *.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Michael G Schwern wrote:
> Anyhow, I'm willing to let that drop, but I want figure out A) why its
> failing so early because it might be masking a bug, this is not
> predicted behavior, and most importantly B) to get it to error, or at
> least warn.
>
> I know B is possible, I did it for Time::y2038. I'll figure that part
> out and try to dig into A. I would like to call B a blocker for 5.12.
Found the bug, patch attached.
v_tm_tday is an NV, so casting time to an integer will cause an overflow
2**31 days after 1970 or somewhere between 2**47 and 2**48. Not sure why the
compiler didn't warn about that.
This makes it work until the year overflows.
As for putting in a warning, there's two options:
1) A few days before the 32 bit year overflows.
2) At some reasonable point before there's too much floating point inaccuracy.
The possibility of long doubles will make #2 difficult to nail down, but I'll
be happy with +/- 2**53.
--
24. Must not tell any officer that I am smarter than they are, especially
if it's true.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
From 9e940e610ac5b2fbb09a554f505963094a4a0745 Mon Sep 17 00:00:00 2001
From: Michael G. Schwern <schwern@pobox.com>
Date: Sun, 31 Jan 2010 02:24:50 -0800
Subject: [PATCH] Type conversion bug in gmtime64 that was causing it to crap out around 2**48
Signed-off-by: H.Merijn Brand <h.m.brand@xs4all.nl>
|
| |
|
|
|
|
|
|
|
| |
This means it should run on anything that does not have a 64-bit
integer type available but does have a double. Presumably this
includes platforms that define PERL_MICRO, so we now use the
same extended time implementation for everything that runs Perl.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All of the time64 functions are only visible within pp_sys.c and are not
part of the public API, so make them all static and give them the S_ prefix.
A side effect of this is that we now unambiguously use S_localtime64_r and
S_gmtime64_r and should no longer collide with system-supplied versions, if
any.
One possible future direction is that if and when Configure detects any
system-supplied *time64_r functions, their prototypes, and their valid
time ranges, we could optionally select those instead of the home-grown
ones.
Another possible future direction is that we could s/S_/Perl_/ and make
the *time64_r functions part of the public API in some post-5.10.x
release. Currently they are only exposed to the outside world via
Perl_pp_gmtime.
Also gave some TRACE macros more specific names.
|
|
|
|
|
|
|
| |
Silence the following build warning:
time64.c:169: warning: 'check_tm' defined but not used
Message-ID: <1ff86f510901081219q4f5f25a3od89c4e5ac03e8664@mail.gmail.com>
|
| |
|
|
|
|
| |
They definitely need it on VMS.
|
| |
|
|
|
|
|
|
| |
Fix trailing #endif.
Remove C99 macro.
|
|
|
|
|
|
|
|
|
|
|
| |
Add trace code.
Fix implied negative time in localtie64_r(). This fixes Windows.
Put in some more tests around small negative and positive times to
try and catch the above.
Explain the loss of accuracy due to use of doubles in perlport.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Configuration information split out into its own header.
Added files to MANIFEST
Turn off USE_SYSTEM_GMTIME, ours is more reliable and possibly faster.
Fix type warnings found on Windows.
Remove unnecessary use of floor() and ceil().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LOCALTIME_MAX to 0x7fff573e.
Update from y2038.
Use the new TM64 struct so years can go out past y2**31
Defines a Year type to avoid converting years to ints.
Remove the TIMGM work around code, using timegm64() is fine and it
saves us from having to convert from TM to tm.
Make functions private with static rather than the _foo convention.
Even faster for distant dates.
|
|
file isn't about just localtime() anymore.
|