Chaim Frenkel wrote:
>
> Strange thought just crossed my mind.
>
> Would having a time object that is understood by perl be sufficient?
> It would smell and taste like an integer but would otherwise be
> magical.
This is something that should be easily doable if RFC 73, "All Perl core
functions
All-
I'm writing a prototype for RFC 99, Standardize ALL Perl platforms on
UNIX epoch, which does some simplistic manipulation of CORE::time to
return the UNIX epoch on all platforms.
My question is: Are there any system-specific epochs that Perl uses
other than MacPerl's? If so, what are they?
> Standardize ALL Perl platforms on UNIX epoch
I've seen lots of discussion on this, and there have been 2 previous
versions worth of discussion as well. The first version of this was
actually entitled:
"Maintain internal time in Modified Julian (not epoch)"
but that got shot down so fast it
Chris Nandor wrote:
>
> >just assume "All Perl core functions should return objects", and hence
> >the reason I wrote RFC 73. ;-)
>
> And it would make me stop using Perl faster than your object method could
> be resolved.
Is your concern one of?
1. Speed
2. Bloat
3. Excess burden o
Russ Allbery wrote:
>
> Is Perl keeping UTC or TAI? If we're standardizing on an epoch, we should
> also standardize on a clock; the difference is over ten seconds.
I think we should definitely maintain this in UTC, since this is how
UNIX works natively. If we're standardizing on the UNIX epoc
Nathan Wiger wrote:
>
> I think we should definitely maintain this in UTC, since this is how
> UNIX works natively. If we're standardizing on the UNIX epoch we should
> standardize on UTC clock as well.
Blech. Now I'm not sure after re-reading the thread starting
Jonathan Scott Duff wrote:
>
> I still think one of the options to the C routine could be the
> offset from UTC or a code ref to a subroutine that can determine the
> offset given the current UTC. That way the user could specify what
> localtime means (even if it doesn't really mean local time ;-
Jonathan Scott Duff wrote:
>
> Or would C just use C and punt to the OS/C RTL/etc.?
Yes, I believe that would be the idea. Or something else exactly like it
;-). Resolving localtime is not our concern; presenting it in a
human-usable format is. And there's no reason you couldn't do this:
use
