me out one second off in my calculation between Unix and Mac OS; I
think this is a leap second issue. I don't know how important it is.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
GMT, 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/
be implemented that you haven't shared (aside from the offset,
because that simply brings us back to "offset from what?").
>have multiple. All that is required that a perl program be able
>to determine portably what the difference between the syscall idea
>of time and so
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 objec
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
I wrote RFC 73. ;-)
And it would make me stop using Perl faster than your object method could
be resolved.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
At 17:11 -0400 2000.09.15, Chaim Frenkel wrote:
>>>>>> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>
>>> This new module to cover your feature would require that it know every
>>> known epoch and timesystem (or at least the useful ones.)
ls will work pretty much the
>CN> same whether we change time() to return native or Perl epoch.
>
>I'm on the side of no change. Just enough 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 y
At 9:17 -0400 2000.09.15, Chaim Frenkel wrote:
>>>>>> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>
>CN> At 22:19 -0400 2000.09.14, Chaim Frenkel wrote:
>>> If you want to adjust for timezones just calculate the constant. Which
>>
oint, and if so, what
it is. I am not trying to be difficult. Maybe I am just tired, but I am
not sure what you are trying to say.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
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 h
At 11:59 -0400 2000.09.14, Andy Dougherty wrote:
>On Thu, 14 Sep 2000, Chris Nandor wrote:
>
>> Well, Perl is about making things easy. What is the most common case,
>> needing an arbitrary value of time that may or may not be used to transfer
>> between platforms, or
epoch were 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 Sourc
True. In Mac OS, time_t is unsigned long (that is how it can start at
1904-01-01 00:00:00 (local time) and still be valid today while still being
32 bits :).
>Maybe POSIX makes more guarantees.
I don't think it does, but I am not sure.
--
Chris Nandor [EMAIL PROT
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.
perl's time and 1 would be native time, or something.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
need to handle datetime. (And I find it
>easier to read the ISO version than a time in seconds)
I think it would be reasonable to have a quick-and-easy way to get the time
in the extended ISO format, as Russ noted it.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
t;an awful lot of Windows users.
I don't think so; AFAIK, the epoch is the same in Windows as in Unix.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
If we stick with it, then I will make
Time::Epoch convert between Mac OS and Unix time, and any other epoch we
deem necessary.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
correct time on Unix:
print scalar localtime $perlsec;
# correct time on Mac OS (-0400):
print scalar localtime $epochsec;
I should put it up on CPAN. If anyone wants it, let me know.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
it when apps are compiled to be 64 bit:
Interesting. I still think we should have our own real 64-bit time,
though, since not all platforms will be 64 bit (although by 2020 they may
be), and perhaps not all of them will be LP64 (and I confess to not know
what that stands for :).
--
At 17:44 +0200 2000.08.22, Markus Peter wrote:
>--On 22.08.2000 11:18 Uhr -0400 Chris Nandor wrote:
>
>> If there's a good reason to remove localtime(), then fine. But please say
>> something more than "web applications don't need it."
>
>Well, I di
ings which don't need to be taken out.
If there's a good reason to remove localtime(), then fine. But please say
something more than "web applications don't need it."
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
* 36;
} else {
require Time::Local;
$tz_offset = sprintf "%+0.4d\n", (Time::Local::timelocal(localtime)
- Time::Local::timelocal(gmtime));
}
return $tz_offset;
}
Returns:
966770661
966770661
3049601062
Sun Aug 20 07:24:22 2000
--
Chris Nandor | [EMAIL PROTECTED] | http://pudge.net/
Andover.Net| [EMAIL PROTECTED] | http://slashcode.com/
Here are some comments from Matthias Neeracher, the MacPerl author, and a
few comments from me.
>To: Chris Nandor <[EMAIL PROTECTED]>
>Subject: Re: Fwd: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
>Date: Wed, 16 Aug 2000 07:31:25 +0200
>From: Matthias Ulrich
to 32-bit integers
>(they moved the epoch from 1970 to 1971, I think, when their previous
>size of integer was about to run out of space, then when it ran out
>again next year they said "yeah, ok, wrong solution" :-).
Yeah; if you change us Macs to 1970 instead of 1904, we actua
26 matches
Mail list logo
