> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
CN> At 13:23 +0200 2000.09.20, Bart Lateur wrote:
>> This surely was a bad design decision from the hardware guys. Very
>> shortsighted.
CN> I don't know if it has anything to do with the hardware clock. It has to
CN> do with what the Mac O
On 20 Sep 2000 13:03:22 -0700, Russ Allbery wrote:
>It's not a hardware problem; the hardware clock just keeps a time. It has
>no concept of time zones.
I thought later on that I wrote this the wrong way. What I ment was: the
guys who did the interface to the hardware.
>It's a software problem
Bart Lateur <[EMAIL PROTECTED]> writes:
> This is bad. That system is broken. ;-) I guess that it's the same
> situation on MS-DOS, since there the hardware clock is usually set to
> local time. It could even happen on Win32?!?
> This surely was a bad design decision from the hardware guys. Very
At 13:23 +0200 2000.09.20, Bart Lateur wrote:
>This surely was a bad design decision from the hardware guys. Very
>shortsighted.
I don't know if it has anything to do with the hardware clock. It has to
do with what the Mac OS API returns for seconds since epoch. The
difference from GMT, or the
On Mon, 18 Sep 2000 11:42:50 -0400, Chris Nandor wrote:
>>But the OS's idea of the epoch is global!
>
>No, it isn't! On Mac OS, I can change my epoch by changing my time zone.
>If it is harcoded into Config.pm, I am fucked.
This is bad. That system is broken. ;-) I guess that it's the same
situ
At 11:21 -0400 2000.09.18, Chaim Frenkel wrote:
>CN> I don't think you understand ... if you use $ENV{TZ}, at least it can be
>CN> changed for each user, for when you change time zones, DST, etc. For
>CN> Config.pm, you have to edit a global value. Ick.
>
>But the OS's idea of the epoch is globa
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
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
> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
CN> Why? File::Spec is in the core. So are multitudinous
CN> ExtUtils::MM_* modules.
>>
>> Covers the platforms that have perl ports. Your problem requires solutions
>> for platforms that don't have a perl port. (yet :-)
CN> No, you misun
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 objects",
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 objects", and hence
>the reason I wrote RFC 73. ;-)
And it w
> 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
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.) Something
>>> this domain knowledgable shouldn't be in
> "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.) Something
>> this domain knowledgable shouldn't be in CORE.
CN> Why? File::Spec is in the core. So are m
At 15:55 -0400 2000.09.15, Chaim Frenkel wrote:
>CN> * We do not know if it will always be this simple for every platform
>
>Hard to see how the three variables wouldn't cover the spectrum.
Very hard to see, until we know what the disparate platforms might require. :)
>CN> * You might need to
> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>> my_time_in_local_epoc
>> + current_os_epoch_offset
>> - timezone_ofset_in_seconds
>> = time_in_unix_epoch_seconds
CN> But again, I don't know what you are trying to say. Are you saying we
CN> should have some global "constant"? If so, y
On Fri, 15 Sep 2000 11:58:08 -0400 (EDT), Andy Dougherty wrote:
>[Aside: Does this mean that make(1) is useless for one hour after
>standard time resumes?]
That'll teach you. You shouldn't be programming in the middle of the
night.
--
Bart.
On Fri, 15 Sep 2000, Chris Nandor wrote:
> You can only avoid breakage with current scripts if you make no changes to
> the current facilities (which is what Andy proposed).
Well I have to admit that I was unaware that on Mac and VMS (without the
wizardry in vms/vms.c) the value returned by time
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
>>> since you are giving it in HHMM format you might as well just
On Thu, 14 Sep 2000 19:19:34 -0400, Chris Nandor wrote:
>And yes, sometimes the OS is completely lacking in knowledge of a
>time zone.
This problem isn't new. Currently, Perl must know the timezone to be
able to correctly generate gmtime() and localtime().
--
Bart.
At 22:19 -0400 2000.09.14, Chaim Frenkel wrote:
>If you want to adjust for timezones just calculate the constant. Which
>since you are giving it in HHMM format you might as well just calculate
>directly.
>
>So what am I missing.
Beats me. I am not sure whether or not you have a point, and if so,
> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>> This is a wider
>> problem then a fixed epoch for perl. Let's turn this around. What if
>> we are on a platform that doesn't use perl's epoch and we need to write
>> a value to a file?
CN> Yes. What if? That's what we're addressing. Ri
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 complicat
Bart Lateur <[EMAIL PROTECTED]> writes:
> Now, on those platforms without 64 bit support, a double float has a lot
> more mantissa bits than 32, typically 50-something (on a total of 64
> bits). This means that all integers with up to more than 50 significant
> bits can exactly be represented. Th
Philip Newton <[EMAIL PROTECTED]> writes:
> You have another assumption up there: that time_t == signed long (since
> you're printing it with %ld) with a resolution of seconds (since you say
> "%ld seconds"). ISO/IEC 9899:1999 (draft C standard, the only C
> standard-y thing I have around) says t
> "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 complicated than that. For example, Mac OS epoch
CN> begins a
On 13 Sep 2000 14:22:30 -0700, Russ Allbery wrote:
>I think it should be specified that the return value is seconds since Unix
>epoch and the storage size be left unspecified, from the language
>perspective. On those platforms that support it, using 64 bits is
>obviously a good idea.
64 bits is
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 needing a value of time that
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 needing a value of time that is specific to a given
> platform?
> And I can
At 11:15 -0400 2000.09.14, Charles Lane wrote:
>I've been in the Epoch !=0 mode and it sucked. I vote for Epoch=0 as
>the default.
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,
At 11:05 -0400 2000.09.14, Philip Newton wrote:
>You have another assumption up there: that time_t == signed long (since
>you're printing it with %ld) with a resolution of seconds (since you say
>"%ld seconds"). ISO/IEC 9899:1999 (draft C standard, the only C standard-y
True. In Mac OS, time_t i
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
Andy Dougherty <[EMAIL PROTECTED]> writes:
On Thu, 14 Sep 2000, Charles Lane wrote:
>> On at least some non-Unix systems, the time() function is itself an attempt
>> to emulate Posix functionality...note that I say "attempt". And also note
>
>Do you mean that the following program might not print
On Thu, 14 Sep 2000, Andy Dougherty wrote:
> Do you mean that the following program might not print '5' (well, about 5,
> given sleep's uncertaintites ...)
>
> #include
> #include
> #include /* May need sys/time.h instead */
> int main(void)
> {
>time_t start,
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 to the
specific issue at hand better than the proposed
At 10:08 -0400 2000.09.14, Andy Dougherty wrote:
>This is not a simple either-or. Suppose you are using a Mac and that
>perl6 decides to use the Unix epoch. Suppose you want to communicate with
>other Mac programs or library functions about time (e.g. perhaps by
>calling things through the XS in
On Thu, 14 Sep 2000, Charles Lane wrote:
> From the perspective of a non-Unix user that has been fighting this battle
> for a few years now, you can't just take the C library time() on all systems.
Sorry, I don't know what that sentence means.
> On at least some non-Unix systems, the time() f
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> "AD" == Andy Dougherty <[EMAIL PROTECTED]> writes:
>AD> In my humble opinion, I think perl's time() ought to just call the C
>AD> library's time() function and not waste time mucking with the return
>AD> value. Instead, if the time is to be stored e
At 0:12 -0400 2000.09.14, Chaim Frenkel wrote:
>Possibly a few functions to make it easy.
>
>$Perl::EpochOffset
>
> 0 on a unix box
> 966770660 on a Mac (Lifted from pudge's previous email)
> etc.
>
>Then on output. print time()-$Perl::EpochOffset;
No, that w
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> One other that might be useful is have strftime() (or something similar)
> built-in without having to use POSIX; and the default should be
> MMDDHHMMSS.fff, (the ISO format)
The more commonly-used ISO format is the extended format rather than t
> "AD" == Andy Dougherty <[EMAIL PROTECTED]> writes:
AD> In my humble opinion, I think perl's time() ought to just call the C
AD> library's time() function and not waste time mucking with the return
AD> value. Instead, if the time is to be stored externally for later use by
AD> another progr
Michael G Schwern <[EMAIL PROTECTED]> writes:
> And if we're going to standardize on something, let's squeeze as much
> out of this as possible. signed 64 bit integer and microseconds. (I
> think that's another RFC)
I think it should be specified that the return value is seconds since Unix
epo
At 16:04 -0400 2000.09.13, Andy Dougherty wrote:
>> If we standardize on the Unix epoch (although possibly with 64 bits), this
>> won't be an issue for the overwhelming majority of users.
>
>Are you sure? Won't this affect Windows as well as Mac users? There are
>an awful lot of Windows users.
On Wed, 13 Sep 2000, Chris Nandor wrote:
> At 14:30 -0400 2000.09.13, Andy Dougherty wrote:
> >2. (RFC 99 way): If you store the time from within a perl program and
> >then read it with a C program on the SAME OS, then you might have a
> >problem.
>
> That is what Time::Epoch should address, I
At 14:30 -0400 2000.09.13, Andy Dougherty wrote:
>2. (RFC 99 way): If you store the time from within a perl program and
>then read it with a C program on the SAME OS, then you might have a
>problem.
That is what Time::Epoch should address, I hope.
If we standardize on the Unix epoch (although
On Wed, 13 Sep 2000, Michael G Schwern wrote:
> > All versions of Perl on all platforms should maintain time both
> > internally and externally as seconds since the UNIX epoch (00:00:00 01
> > Jan 1970 UTC).
> Color me obvious, but could you discuss some of the practical
> situations where this
At 5:34 -0400 2000.09.13, Michael G Schwern wrote:
>On Wed, Sep 13, 2000 at 07:10:30AM -, Perl6 RFC Librarian wrote:
>> Currently, internal time in Perl is maintained via C, which is
>> highly system-dependent. On some systems, this is relative to the UNIX
>> epoch, while others use their own
On Wed, Sep 13, 2000 at 07:10:30AM -, Perl6 RFC Librarian wrote:
> Currently, internal time in Perl is maintained via C, which is
> highly system-dependent. On some systems, this is relative to the UNIX
> epoch, while others use their own epochs (MacPerl uses 1904, for
> example).
>
> All ver
On 13 Sep 2000 07:10:30 -, Perl6 RFC Librarian wrote:
>In addition, a C function should be added which provides access
>to the native epoch/system time. For simplification, it might be best if
>this C function remain the basis for other library-related
>functions, such as C, C, and so on, whi
49 matches
Mail list logo
