At 11:01 -0400 2000.09.14, Andy Dougherty wrote:
On Thu, 14 Sep 2000, Chris Nandor wrote:
There's also the possibility of time accepting an argument, where 0 would
be perl's time and 1 would be native time, or something.
Now that's a clever idea. Hmm. I think I like it as a solution
used for MacPerl, I don't think I would _ever_ need to get the
Mac OS epoch (though I would certainly want it available if necessary). I
can't say the same for VMS, or for other Mac users.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network
At 17:47 -0400 2000.09.14, Chaim Frenkel wrote:
"CN" == Chris Nandor [EMAIL PROTECTED] writes:
CN No, that won't really work. When my offset from GMT changes for daylight
CN savings time, it will break. The point of having a module is that epoch
CN conversions are more compli
ough that a user can determine how
to offset the return from time, to pass to other data sinks.
If you want no change, then what are you offset from? If time() remains
system-dependent, then we have nothing against which to offset it.
--
Chris Nandor [EMAIL PROTECTED]ht
At 11:56 -0400 2000.09.17, Chris Nandor wrote:
At 11:10 -0700 2000.09.16, Nathan Wiger wrote:
Now, one thing that should probably be explored is creating a time
object, similar to the date object specified in RFC 48. In fact, I'd
just assume "All Perl core functions should return ob
At 9:08 -0700 2000.09.18, Nathan Wiger wrote:
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
, or the difference from anything, cannot be hardcoded,
because it is dynamic, depending on what timezone you are in at the moment.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
