Re: RFC 48 (v4) Replace localtime() and gmtime() with date() and utcdate()

[Bart Lateur]

On Tue, 26 Sep 2000 08:10:39 -0700, Nathan Wiger wrote:

>Well, you can easily do this already with
>
>   $date = utcdate (time + $offset);
>
>Or even:
>
>   $date = utcdate (time + &getoffset('US/Pacific'));

Unfortunately, because Daylight Saving Time is largely equivalent to
Time Zones, $offset depends on the time.

-- 
Bart.

Re: RFC 48 (v4) Replace localtime() and gmtime() with date() and utcdate()

[Russ Allbery]

Jonathan Scott Duff <[EMAIL PROTECTED]> writes:

> Do you mean local time now or local time for all time?  The former is
> easy, the latter hard.  Well, it's not hard for those places where the
> offset from UTC has remained (mostly) constant, but there are some
> places that have an offset from UTC that is a function of time more
> complex than daylight savings.

> Or would C just use C and punt to the OS/C
> RTL/etc.?

It should just punt.  ANSI/ISO C already requires that the C localtime
call deal with all of this.  We can look at providing our own localtime if
the system is grossly deficient in this respect, but that's an internals
rather than a language issue.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 48 (v4) Replace localtime() and gmtime() with date() and utcdate()

[Nathan Wiger]

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 Date::Timezones qw/sec_offset/;
   $localtime = utcdate (time + sec_offset('US/Pacific'));

But this functionality wouldn't have to be in core.

-Nate

Re: RFC 48 (v4) Replace localtime() and gmtime() with date() and utcdate()

[Jonathan Scott Duff]

On Tue, Sep 26, 2000 at 08:10:39AM -0700, Nathan Wiger wrote:
> And having a date() that returns local time, which will be most-used,
> is still a good thing, I think.

Do you mean local time now or local time for all time?  The former is
easy, the latter hard.  Well, it's not hard for those places where the
offset from UTC has remained (mostly) constant, but there are some places
that have an offset from UTC that is a function of time more complex
than daylight savings.

Or would C just use C and punt to the OS/C RTL/etc.?
If so, I'll shut up.  But if not, I think that we should provide a
solution that works everywhere by letting the user decide their own
offset from UTC.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 48 (v4) Replace localtime() and gmtime() with date() and utcdate()

[Nathan Wiger]

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 ;-).

Well, you can easily do this already with

   $date = utcdate (time + $offset);

Or even:

   $date = utcdate (time + &getoffset('US/Pacific'));

Or even:

   $date = date (time - &getoffset('UTC'));

Anything having to do with numeric offset it already implicitly
supported (as in Perl 5). And having a date() that returns local time,
which will be most-used, is still a good thing, I think.

-Nate

Re: RFC 48 (v4) Replace localtime() and gmtime() with date() and utcdate()

[Jonathan Scott Duff]

On Tue, Sep 26, 2000 at 05:49:38AM -, Nathan Wiger wrote:
> =head1 NOTES ON FREEZE
> 
> Everyone felt pretty good about this, I think. The only thing we'd all
> probably like to see is one single C function, but unfortunately
> dealing with timezone specifications is an extraordinarily difficult
> issue. 

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 ;-).

And, in order to make this scenario more useful, as part of the standard
Perl distribution we would have a module that defines constants for all
of the "common" timezones.

$t1 = date(offset => -6 * 60 * 60); # offset in seconds (CST)
$t2 = date(offset => -5 * 60 * 60); # offset in seconds (CDT)

$t3 = date(offset => \&offsetsub);  # UTC passed as first
# parameter to offsetsub()

use Timezones;
$t4 = date(offset => CST6CDT);  # US/Central
$t5 = date(offset => \&zone('US/Central')); # US/Central

(made up syntax, of course)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]