On Wed, 9 Aug 2000 22:57:34 -0500, Jonathan Scott Duff wrote:
By "local timezone" do you mean that some sort of inspection happens to
determine the local timezone and the date() intrinsically knows about it?
What about daylight savings time? I presume the ability to specify an
offset from GMT
Jonathan Scott Duff [EMAIL PROTECTED] writes:
By "local timezone" do you mean that some sort of inspection happens to
determine the local timezone and the date() intrinsically knows about
it? What about daylight savings time?
This all should be handled by the operating system. If you call
On Thu, Aug 10, 2000 at 09:30:05AM -0700, Russ Allbery wrote:
Bart Lateur [EMAIL PROTECTED] writes:
As for the parameter's format: GMT is easy, you can pass "GMT" (or
"+"). For localtime(), you often don't explicitely know the time
zone and Daylight savings Time rule, so this looks
On Thu, 10 Aug 2000 14:39:39 -0500, Jarkko Hietaniemi wrote:
people in Newfoundland are going to expect to be
able to pass in -0230 and have that work, and that's interestingly hard.
What's so hard? Subtracting 2 hours and 30 minutes from the official
referential time (GMT)? Or the Daylight
On Fri, Aug 11, 2000 at 02:09:43AM +0200, Bart Lateur wrote:
On Thu, 10 Aug 2000 14:39:39 -0500, Jarkko Hietaniemi wrote:
Did not.
people in Newfoundland are going to expect to be
able to pass in -0230 and have that work, and that's interestingly hard.
What's so hard? Subtracting 2
At 02:39 PM 8/10/00 -0500, Jarkko Hietaniemi wrote:
There are quarter-hour time zones...
And then there's Damian, who lives in a non-linear time zone...
--
Peter Scott
Pacific Systems Design Technologies
Bart Lateur [EMAIL PROTECTED] writes:
What's so hard? Subtracting 2 hours and 30 minutes from the official
referential time (GMT)? Or the Daylight Savings Time rules?
It's not a problem of implementation. It's a problem of semantics due to
the way Perl parses the language.
Suppose you call:
On Tue, Aug 08, 2000 at 10:47:10PM -0700, Russ Allbery wrote:
John Tobey [EMAIL PROTECTED] writes:
On Wed, Aug 09, 2000 at 02:22:22AM +0200, Bart Lateur wrote:
date() would be more general, and replace both. You can pass it a time
zone, ANY time zone, and it will tell you what time it is
On Wed, Aug 09, 2000 at 10:10:29AM -0700, Nathan Wiger wrote:
Agreed. General-purpose timezone support is scheduled for a swift and
painless death in the next version of RFC 48. Only the local timezone
and GMT will be included in the RFC, same as now.
By "local timezone" do you mean that some
On Mon, Aug 07, 2000 at 01:44:28AM -0500, Jonathan Scott Duff wrote:
On Sun, Aug 06, 2000 at 11:07:02AM -0700, Russ Allbery wrote:
Basically, you don't want to go anywhere near this mess; it eats people.
I agree.
I see two reasonable options to
While I think Time::Object is a really great module, and following these
discussions I'm thinking of adding a date() function to it
Aaah! Please don't. :-) Name it something else, por favor (or at least
wait until this is finalized and make the interface the same).
date arithmetic...not
On Tue, Aug 08, 2000 at 09:46:04AM -0700, Nathan Wiger wrote:
The RFC doesn't mention localtime() for just this reason. The idea would
be localtime would be GONE in Perl 6, instead moved to Time::Local.
date() would replace it.
Why is this a good idea? Perl programs have been using
On Tue, 8 Aug 2000, Nathan Wiger wrote:
While I think Time::Object is a really great module, and following these
discussions I'm thinking of adding a date() function to it
Aaah! Please don't. :-) Name it something else, por favor (or at least
wait until this is finalized and make the
On Tue, Aug 08, 2000 at 09:50:27PM +0100, Matt Sergeant wrote:
All I can say to that is, ugh! I don't want to see Perl6 be so
fundamentally different to perl5 that I have to translate every single
script. I want some better stuff, but a new language is not what I'm
looking for.
All of your
"JP" == John Porter [EMAIL PROTECTED] writes:
JP Matt Sergeant wrote:
I don't want to see Perl6 be so
fundamentally different to perl5 that I have to translate every single
script. I want some better stuff, but a new language is not what I'm
looking for.
JP Well, I guess we
On Tue, 8 Aug 2000 11:51:36 -0700, Damien Neil wrote:
The idea would
be localtime would be GONE in Perl 6, instead moved to Time::Local.
date() would replace it.
Why is this a good idea? Perl programs have been using localtime() for
over a decade. Why do we suddenly want to make them all
On Wed, Aug 09, 2000 at 02:22:22AM +0200, Bart Lateur wrote:
I have a server in the UK, while I'm in Belgium. Different time zones.
So localtime() won't return the time in *my* localtime.
So we have two almost identical functions in the core, gmtime and
localtime, where one gives an offset
John Tobey [EMAIL PROTECTED] writes:
On Wed, Aug 09, 2000 at 02:22:22AM +0200, Bart Lateur wrote:
date() would be more general, and replace both. You can pass it a time
zone, ANY time zone, and it will tell you what time it is in that time
zone.
You're proposing embedding the full power of
On Sun, Aug 06, 2000 at 01:10:23PM -0700, Nathan Wiger wrote:
So you see why we need a persistent format() function. However, I think
your real issue is a one-time call that just changes the format
temporarily:
print $date-strftime('%H:%M'); # print the time
print "$date";
On Mon, Aug 07, 2000 at 01:44:28AM -0500, Jonathan Scott Duff wrote:
On Sun, Aug 06, 2000 at 11:07:02AM -0700, Russ Allbery wrote:
Basically, you don't want to go anywhere near this mess; it eats people.
I agree.
I see two reasonable options to go with instead. One is to just use a
Whatever you do, don't use those timezone names. Is EST Eastern US time
or Eastern Standard Time in Australia? The same abbreviation is used in
both places.
Naming of time zones is a *huge* rathole that you probably just don't want
to crawl into. The short abbreviations are *not*
Me too, and I'm _not_ an astronomer.
Tim Jenness wrote:
Also, I would vote for a method to return the Julian date (yes I am an
astronomer...) :-)
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_NetZero
Also, I would vote for a method to return the Julian date (yes I am an
astronomer...) :-)
But surely not as a part of the core language?
Exactly. In fact, I'm going to chop a lot of the original proposal out.
It's too bloated for core.
There's a lot of cool time/date stuff, but
Andy Dougherty wrote:
On Mon, 7 Aug 2000, Glenn Linderman wrote:
Me too, and I'm _not_ an astronomer.
Tim Jenness wrote:
Also, I would vote for a method to return the Julian date (yes I am an
astronomer...) :-)
But surely not as a part of the core language?
It isn't that
On Mon, 7 Aug 2000, Tim Jenness wrote:
Is localtime() used often enough to justify being part of
the language?
You're kidding, right?
We wouldn't have had all those script kiddies complaining about year 19100
bugs and month-being-off-by-one errors if localtime() wasn't being used
all of the
On Mon, 7 Aug 2000, Nathan Wiger wrote:
Also, I would vote for a method to return the Julian date (yes I am an
astronomer...) :-)
But surely not as a part of the core language?
Exactly. In fact, I'm going to chop a lot of the original proposal out.
It's too bloated for core.
On Sun, Aug 06, 2000 at 01:41:06PM -, Perl6 RFC Librarian wrote:
$scalar = date; # scalar ctime date, same as current
$object = date; # object with accessor functions (new)
How are these distinguished?
K.
--
Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/
Perl6 RFC Librarian [EMAIL PROTECTED] writes:
I like this proposal, although I do have a lot of remarks.
Consider them constructive!
The C$time specifier can be followed by a C$timezone argument,
s/$time/$format/
which returns the date relative to that timezone. By default, the time
is
In message [EMAIL PROTECTED]
[EMAIL PROTECTED] (Johan Vromans) wrote:
I'd argue that
($year, $mon, $mday, $hour, $min, $sec, $msec, $nsec,
is much easier to remember, since it is a series of continuous
decrasing magnitudes.
I was thinking much the same. It also means you can
Perl6 RFC Librarian [EMAIL PROTECTED] writes:
The C$time specifier can be followed by a C$timezone argument, which
returns the date relative to that timezone. By default, the time is
returned relative to the local timezone. You can get UTC, for example,
by specifying CUTC or CGMT as the
On Sun, 6 Aug 2000, Tom Hughes wrote:
In message [EMAIL PROTECTED]
[EMAIL PROTECTED] (Johan Vromans) wrote:
I'd argue that
($year, $mon, $mday, $hour, $min, $sec, $msec, $nsec,
is much easier to remember, since it is a series of continuous
decrasing magnitudes.
I
The C$time specifier can be followed by a C$timezone argument,
s/$time/$format/
Ooops! Thanks. :-)
Allow numeric (e.g. minutes? seconds?) displacement?
This would also allow
$tomorrow = date(undef,undef,24*60*60);
Good call. The function could use a string as a timezone, or a number
On Sun, 06 Aug 2000, Gisle Aas wrote:
How about using a float (fractional second) instead of $msec, $nsec.
Or in addition to.
The problem with fractional seconds is that you can't really tell
exactly how precise your measurements are.
Here, at least, you could have an undef for the
On Sun, Aug 06, 2000 at 01:41:06PM -, Perl6 RFC Librarian wrote:
$scalar = date; # scalar ctime date, same as current
@array = date; # array of date/time values (new order)
%hash= date; # hash of date/time values (new)
$object = date; # object with
Yes! Yes!
How about using a float (fractional second) instead of $msec, $nsec.
Works for me (it's for you anyways). ;-)
-Nate
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace localtime() and gmtime() with date()
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 05 Aug 2000
Version: 1
Status: developing
Mailing List: [EMAIL PROTECTED]
36 matches
Mail list logo
