Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch by Chaim Frenkel- September 15, 2000 >>>>> "CN" == Chris Nandor <pudgepobox.com> writes:>> my_time_in_local_epoc>> + current_os_epoch_offset>> - timezone_ofset_in_seconds>> = time_in_unix_epoch_secondsCN> But again, I don&39;t know what you are trying to say. Are you saying weCN> should have some global "constant" If so, you still have problems:Sure, we have plenty of global constants. It could either be an UPPERCASEor something in the Perl:: namespace.CN>.http://www.nntp.perl.org/group/perl.perl6.language.datetime/2000/09/msg66.html Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch by Bart Lateur- September 15, 2000 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 resumesThat&39;ll teach you. You shouldn&39;t be programming in the middle of thenight.-- Bart.http://www.nntp.perl.org/group/perl.perl6.language.datetime/2000/09/msg65.html Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch by Andy Dougherty- September 15, 2000 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 thewizardry in vmsvms.c) the value returned by time() could jump behind yourback if you were running when DST kicked in or out. If it were justdifferent absolute epochs, I would tend to oppose the proposal (andrecognize that I am probably in the...http://www.nntp.perl.org/group/perl.perl6.language.datetime/2000/09/msg64.html Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch by Chris Nandor- September 15, 2000 At 9:17 -0400 2000.09.15, Chaim Frenkel wrote:>>>>>> "CN" == Chris Nandor <pudgepobox.com> 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 calculate>>> directly.>>>>>> So what am I missing.>>CN> Beats me. I am not sure whether or not you have a...http://www.nntp.perl.org/group/perl.perl6.language.datetime/2000/09/msg63.html Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch by Bart Lateur- September 15, 2000 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&39;t new. Currently, Perl must know the timezone to beable to correctly generate gmtime() and localtime().-- Bart.http://www.nntp.perl.org/group/perl.perl6.language.datetime/2000/09/msg62.html Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch by Chris Nandor- September 14, 2000 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, whatit is. I am not trying to be difficult. Maybe I am just tired, but I amnot sure what you are trying to say.-- Chris Nandor pudgepobox.com http:pudge.netOpen...http://www.nntp.perl.org/group/perl.perl6.language.datetime/2000/09/msg61.html Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch by Chaim Frenkel- September 14, 2000 >>>>> "CN" == Chris Nandor <pudgepobox.com> writes:>> This is a wider>> problem then a fixed epoch for perl. Let&39;s turn this around. What if>> we are on a platform that doesn&39;t use perl&39;s epoch and we need to write>> a value to a fileCN> Yes. What if That&39;s what we&39;re addressing. Right now, you need to useCN> something like Time::Epoch to do a conversion, or you use a non-ambiguousCN> representation, such as you...http://www.nntp.perl.org/group/perl.perl6.language.datetime/2000/09/msg60.html Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch by Chris Nandor- September 14, 2000 At 17:47 -0400 2000.09.14, Chaim Frenkel wrote:>>>>>> "CN" == Chris Nandor <pudgepobox.com> writes:>>CN> No, that won&39;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 at Jan 1 1904 00:00:00 _local time_. That is why the timezone>CN> offset from GMT was..http://www.nntp.perl.org/group/perl.perl6.language.datetime/2000/09/msg59.html Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch by Russ Allbery- September 14, 2000 Bart Lateur <bart.lateurskynet.be> 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. That would be a lot better than the> current situation of 32 bits.Everything I&39;ve heard from anyone who&39;s done work on time handlinglibraries is that you absolutely never want to.http://www.nntp.perl.org/group/perl.perl6.language.datetime/2000/09/msg58.html Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch by Russ Allbery- September 14, 2000 Philip Newton <newtonnewton.digitalspace.net> writes:> You have another assumption up there: that time_t == signed long (since> you&39;re printing it with %ld) with a resolution of seconds (since you say> "%ld seconds"). ISOIEC 9899:1999 (draft C standard, the only C> standard-y thing I have around) says that time_t is an "arithmetic type"> (OK, so you&39;re allowed to subtract one from another) "capable of> representing time", and that...http://www.nntp.perl.org/group/perl.perl6.language.datetime/2000/09/msg57.html |