Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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 will be built in to date()? And I still think it would be a good idea to let the user somehow provide an anonymous sub to date() that will tell date() the proper offset from GMT for "localtime" if we're going to support that concept at all. Indeed. The only built-in timezone (and daylight savings time, which is technically the same as a time zone) it really needs, is that of the current lcoaltime(). gmtime() is no offset. For the particular case where I needed this, where the server in another time zone than me, I know the data for the time zone and daylight savings time, so I can pass that data myself. But I have some doubt if you actually need to be able to pass this function a sub ref (AKA a callback). For most of the time, this will be a constant, so passing a constant in the form of "+0200" should be possible as well. I would put all other time zone processing, apart from the local system's localtime() time zone, and including the callback functions, in a module. 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 like a good candidate for undef. -- Bart.
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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 localtime in C, you should get back local time, whatever the local time zone. The whole point is to not try to duplicate that information in Perl core. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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 like a good candidate for undef. The string "GMT" is technically wrong. I'm opposed to allowing one to pass in any sort of string for time zone information; if you allow "GMT", people are going to expect to be able to use "EST", and who knows what they actually mean. If you want GMT, pass an offset of 0. Be careful about time zone offsets, btw, if the interface is going to support them. +0700 is *not* "700 minutes"; it's 7 hours and 0 minutes. And there are half-hour time zones. This is an area where there's a *lot* There are quarter-hour time zones... of potential confusion; people in Newfoundland are going to expect to be able to pass in -0230 and have that work, and that's interestingly hard. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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 Savings Time rules? -- Bart.
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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 hours and 30 minutes from the official referential time (GMT)? Or the Daylight Savings Time rules? Without any further thought I'll just shoot and say the DST rules because they are legislation and fickle, not logic/astronomy and stable. -- Bart. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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: date (time, undef, -0230); What does that mean in terms of time-zone offsets? Are you subtracting 230 seconds from UTC? 230 minutes? A negative octal number? :) The syntax people are used to for specifying time zone offsets *looks* like a number but actually isn't one. You can require that it be passed as a string, but writing something like the above would be a *very* common new user mistake. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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 in that time
zone.
You're proposing embedding the full power of the Olson TZ library into
Perl core. This is a nontrivial amount of data that changes four or five
times a year. I really don't think this is a good idea. Furthermore, the
only time zone database that can actually do this doesn't use the naming
scheme that you're probably used to.
The JTobey::Date module uses the TZ environment variable (which, I'm
told, is non-portable), the esoteric POSIX routines tzset and tzname,
and some functions from the CPAN modules Date::Parse and Date::Format.
It's far worse than non-portable; it's completely insufficient. The POSIX
TZ syntax cannot represent many real time zones. You need the Olson-style
naming scheme which refers to entries in a fairly large external database
You mean the "EST5EDT", "US/Pacific", "America/New_York", and suchlike
files in /usr/share/zoneinfo. Actually, I do use those indirectly,
though probably non-portably, by localizing C$ENV{TZ}. GNU Libc
takes care of finding the zoneinfo file, but lamentably reparses it
every time TZ changes and CPOSIX::tzset is called.
My module does not parse old-style TZ formats, though some other
module (Date::Format or Time::Zone?) does.
-John
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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 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 will be built in to date()? And I still think it would be a good idea to let the user somehow provide an anonymous sub to date() that will tell date() the proper offset from GMT for "localtime" if we're going to support that concept at all. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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
binary flag that says use UTC or not; this is the simplest and most
reliable to explain. The other is to allow a timezone offset; this
doesn't deal with daylight savings time and historic time zone changes,
but it provides enough power for most of what people want to do and if you
want to deal with the rest you have to deal with time zone naming.
I agree completely with Russ, and I would further state that I don't
want this Cdate feature in the core. Dates, times, timezones, leap
seconds, month and day names, localized formats, etc., are too
complex. No one here has thought out the complexity enough to say
"this is what Perl will support from now on".
Currently, there isn't even an adequate (in my opinion) module on CPAN
that gives dates a proper abstract interface. Time::Object may be
okay as a lightweight localtime/strftime interface, but it does not
support date, as opposed to time/date, arithmetic, or rather, it
mis-supports it.
Well its called Time::Object, not Date::Object for a reason... :)
Since we really don't understand dates here, I don't want us commiting
to a certain interface without a `use' directive in the program.
Distribute Time::Object as a standard module, but keep it a module,
and don't force its quirks on people. Certainly, don't force the
complex, quirky, and untested interface being developed here now on
anyone without a long, patient discussion period.
This makes an incredible amount of sense. We could even let the user
specify a coderef to a sub that implements their own particular
timezone oddities. (i.e. a sub to tell date() what the TZ offset is)
Gross. Put it in a module.
While I think Time::Object is a really great module, and following these
discussions I'm thinking of adding a date() function to it, I'm actually in
total agreement with John here. Times and dates are something that should be
supported _simply_ by the core of Perl, and more extensively in an external
module. I'd be very happy to see the Time::Object in core perl as a module,
but I'd hate to see it as the _only_ interface to dates. And the extensions
being proposed here just seem like bloat to me. And John is totally correct:
Time::Object attempts to do some datetime arithmetic, but doing this sort of
thing properly for dates alone is really a tough nut to crack, and not
something that we need put in the core. There are modules out there to do
this sort of thing, lets keep it that way (or improve them enough to put in
core).
The only part of this proposal that I like is Damian's WANTHASH extension
which would allow localtime{'day', 'month', 'year'}.
I'm also really aware that trying to change localtime in an array context to
return the real year is going to be a very painful change. There are lots of
simple scripts that use localtime that I wouldn't have thought people will
want to run through the p5top6 conversion script just to get running on a
newer perl. (and then theres the issue of how you detect the addition of
1900 to the year even using the B::* stuff).
BTW: Since I'm not subscribed to p6-lang (I think you guys would kill my 64k
link!), I'd just like to say that just because strftime() is a unix-ism or
POSIX-ism, does not mean that its bad. Programmers know strftime, they've
heard of strftime, lets not try and confuse things by doing a "Java" and
inventing our own new date formatting functions with new format specifiers.
Perl is not about NIH.
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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 something that we need put in the core.
I'm torn on this one. If it's efficiently done on objects, I think it's
really cool. However, it could be implemented really poorly and suck.
But I'd rather leave it in and let Larry decide to axe it (he suggested
it, after all...)
The only part of this proposal that I like is Damian's WANTHASH extension
which would allow localtime{'day', 'month', 'year'}.
That and returning an object in a scalar context. This is a key shift
I'd like to see in Perl 6 - embedding objects at a low-level and
translating them to strings only on demand.
I'm also really aware that trying to change localtime in an array context to
return the real year is going to be a very painful change.
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.
The syntax of localtime would remain identical. All the translation
script would have to do is add a 'use Time::Local' if localtime was
called, maybe outputting a warning message like
$ ./p52p6 mydatescript
localtime() no longer in core - use date() instead [importing
Time::Local]
I'd just like to say that just because strftime() is a unix-ism or
POSIX-ism, does not mean that its bad.
Yeah, this is a tough call. I agree with you, personally. When I see
strftime() I instantly know what it does. However, I think I've come up
with an alternative that's just as good. I encourage you to check out
v2, probably out by tomorrow. I think you'll like it better.
Cheers,
Nate
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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 localtime() for over a decade. Why do we suddenly want to make them all obsolete? Is the goal of Perl 6 really to require that every Perl program in creation be rewritten? I'm all for adding a new and improved time mechanism with a bit less of the oddness localtime() carries, but does it really hurt us to leave the old style in the core? $ ./p52p6 mydatescript localtime() no longer in core - use date() instead [importing Time::Local] It would be a horrible idea to have every existing Perl program spit out reams of warnings whenever running under Perl 6. Let's keep Perl Perl. Clean up the internals, yes. Remove deprecated features, yes. Add nifty new functionality, yes. Change everything that looks the slightist bit ugly? Please, no. I would humbly offer that Perl 6 should run at least 90% of all old Perl 5 scripts, without translation or compatability modules. If it doesn't, how can it be called Perl? - Damien
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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 interface the same).
Thats the idea...
The only part of this proposal that I like is Damian's WANTHASH extension
which would allow localtime{'day', 'month', 'year'}.
That and returning an object in a scalar context. This is a key shift
I'd like to see in Perl 6 - embedding objects at a low-level and
translating them to strings only on demand.
Well OK, I concede... Lets see how Larry takes to these ideas. Judging by
the fact that this is something he originally suggested, I'm guessing he
might be into it.
I'm also really aware that trying to change localtime in an array context to
return the real year is going to be a very painful change.
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.
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.
I'd just like to say that just because strftime() is a unix-ism or
POSIX-ism, does not mean that its bad.
Yeah, this is a tough call. I agree with you, personally. When I see
strftime() I instantly know what it does. However, I think I've come up
with an alternative that's just as good. I encourage you to check out
v2, probably out by tomorrow. I think you'll like it better.
I take the Cozens stand on this: I don't like "alternatives" if they just
re-implement something that works already.
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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 programs may need translating anyway. They just might be translated on-the-fly by perl6 and all you'd have to do is add a command line switch or add "use Perl5;" or maybe absolutely nothing at all. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
"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 all want something a little different. JP I, for example, want a New, Better language, and I don't care if JP all my scripts need rewriting. (I predict that that will happen JP anyway.) My old stuff will continue to work with perl5. i agree. think about those scripts written under perl4 and are still running with perl4 code. mirror.pl is one well know program that is like that. if they want the new perl6 either run the perl5 through larry's translator or rewrite in 6. i have a new client who also has a major program written in perl4. we are starting a complete rewrite into 5. the fact that it runs is not enough. we need the better data structures and objects that 5 gives us. so many people will want to d a complete rewrite to take full advantage of perl6. i would want the async i/o (assuming it gets in :), many of the cleaner object stuf, etc. i may not care about higher order functions and iterators and such but having them will make for easier to write programs in the fields that want those features. perl6 should be the descendent of perl5, but not its clone. some genetic drift is expected and wanted. and as always larry is the father but we will steal genes from many mothers. :-) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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 obsolete? 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 of zero, and the other an offset based upon the time zone settings of your system. It's a very small difference. Those are the most commonly requested time representations, but as in my example, it's not enough. 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. -- Bart.
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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 of zero, and the other an offset based upon the time zone settings of your system. It's a very small difference. Those are the most commonly requested time representations, but as in my example, it's not enough. 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. Multiple timezone support in a single process should definitely be supported, *ideally*. I don't think this RFC is even proposing that. It is very difficult to do right. I spent several months trying; you can see my work using these CVS commands: echo :pserver:[EMAIL PROTECTED]:/home/cvs A ~/.cvspass cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs co Date The JTobey::Date module uses the TZ environment variable (which, I'm told, is non-portable), the esoteric POSIX routines tzset and tzname, and some functions from the CPAN modules Date::Parse and Date::Format. It is designed to give it all an easy OO interface, and to be as correct as possible on systems like mine. It is not expected to be very fast, portable, or locale-friendly. To overcome these problems would be a Herculean task which I simply doubt that anyone here is willing to do. Therefore, I oppose the notion that Perl 6 will magically handle all this. -John
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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 the Olson TZ library into Perl core. This is a nontrivial amount of data that changes four or five times a year. I really don't think this is a good idea. Furthermore, the only time zone database that can actually do this doesn't use the naming scheme that you're probably used to. The JTobey::Date module uses the TZ environment variable (which, I'm told, is non-portable), the esoteric POSIX routines tzset and tzname, and some functions from the CPAN modules Date::Parse and Date::Format. It's far worse than non-portable; it's completely insufficient. The POSIX TZ syntax cannot represent many real time zones. You need the Olson-style naming scheme which refers to entries in a fairly large external database of time zones and their current and historic data, not just a wide variety of bizarre daylight savings changes but time zone changes that often vary by political whim. (Like Australia fiddling with its daylight savings rules this year because of the Olympics.) People in the EU, where there's a standard for daylight savings, and particularly people in the US, where we haven't changed our rules in quite a while, often don't realize just how baroque this can get. It is designed to give it all an easy OO interface, and to be as correct as possible on systems like mine. It is not expected to be very fast, portable, or locale-friendly. To overcome these problems would be a Herculean task which I simply doubt that anyone here is willing to do. Therefore, I oppose the notion that Perl 6 will magically handle all this. -John -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
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"; # without touching this
Indeed.
I'll put strftime() back in, I think that's probably the best thing for
this.
strftime sounds like a real Unixism to me. 'set_format' and 'format' looks
more neutral and at least as effective.
-- Johan
AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
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 binary flag that says use UTC or not; this is the simplest and most reliable to explain. The other is to allow a timezone offset; this doesn't deal with daylight savings time and historic time zone changes, but it provides enough power for most of what people want to do and if you want to deal with the rest you have to deal with time zone naming. I agree completely with Russ, and I would further state that I don't want this Cdate feature in the core. Dates, times, timezones, leap seconds, month and day names, localized formats, etc., are too complex. No one here has thought out the complexity enough to say "this is what Perl will support from now on". Currently, there isn't even an adequate (in my opinion) module on CPAN that gives dates a proper abstract interface. Time::Object may be okay as a lightweight localtime/strftime interface, but it does not support date, as opposed to time/date, arithmetic, or rather, it mis-supports it. Since we really don't understand dates here, I don't want us commiting to a certain interface without a `use' directive in the program. Distribute Time::Object as a standard module, but keep it a module, and don't force its quirks on people. Certainly, don't force the complex, quirky, and untested interface being developed here now on anyone without a long, patient discussion period. This makes an incredible amount of sense. We could even let the user specify a coderef to a sub that implements their own particular timezone oddities. (i.e. a sub to tell date() what the TZ offset is) Gross. Put it in a module. -John
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
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* standardized and are quite frequently ambiguous. There are three other prevelant time-zone naming schemes: the POSIX one (EST5EDT, for example) is completely insufficient to actually represent time zone variations as they occur in the real world, the "old Olson" found in most Unix operating systems these days with names like US/Pacific doesn't offer enough granularity, and the "new Olson" method (the best of the lot) uses names that most people don't know (America/Los_Angeles for US Pacific for example). Basically, you don't want to go anywhere near this mess; it eats people. Heartily agreed. Having just parsed through several hundreds of megabytes of mailing list archives and having reported to Graham on which various date formats Date::Parse chokes on or returns zero from, I can say with some certainty that one should stay away from timezone names if at all possible. There are many unambiguous/nonstandard/unknown timezone names out there. I see two reasonable options to go with instead. One is to just use a binary flag that says use UTC or not; this is the simplest and most reliable to explain. The other is to allow a timezone offset; this doesn't deal with daylight savings time and historic time zone changes, but it provides enough power for most of what people want to do and if you want to deal with the rest you have to deal with time zone naming. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
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 Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
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 there's plenty of chance for external modules for that (including backwards localtime() compatibility). -Nate
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
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 hard/big; dates are an extremely useful type of value to manipulate; Julian dates are much easier to manipulate than year/month/day. That said, I really don't care if it is core, as long it is available in the standard distribution. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
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 time, whether in CGI code or not. Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
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. There's a lot of cool time/date stuff, but there's plenty of chance for external modules for that (including backwards localtime() compatibility). -Nate Agreed. It was getting a bit out of hand (although in principal Julian date could be the internal format :-) ). What is the reason why any of this has to be in the core? Could all the date/time stuff be moved into a standard module? Is localtime() used often enough to justify being part of the language? -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
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/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
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 returned relative to the local timezone. You can get UTC, for
example, by specifying CUTC or CGMT as the timezone.
Allow numeric (e.g. minutes? seconds?) displacement?
This would also allow
$tomorrow = date(undef,undef,24*60*60);
$object = date time, undef, 'GMT';# return object in UTC
s/UTC/GMT/
GMT is not UTC (although it is equal for most practical purposes).
$hour = 0 .. 24
$min = 00 .. 59 # 0-padded
$sec = 00 .. 59 # 0-padded
Why 0-padding? The only reason to add this is out of frustration due
to localtime's behavior. With the new date function you'll never need
to call
sprintf("%02d/%02d/%04d", $tm[3], $tm[4]+1, $tm[5]+1900);
since you can do
date(undef,"%d/%m/%Y")
or something alike.
Also, why not space-pad the mday?
$isutc = 1 or undef; # is UTC? (see below...)
$tz= PST|UTC|...; # timezone
Isn't $isutc identical to ($tz eq 'UTC')?
A list of date/time values is returned. The ordering and format of these
values has been radically changed to reflect what most of us probably
view as "ordinary":
($mday, $mon, $year, $hour, $min, $sec, $msec, $nsec,
$wday, $yday, $isdst, $isutc, $tz) = date;
This ordering is very easy to remember, in my opinion,
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.
$t-mon # based at 1
$t-_mon # based at 0
Why? Is it so hard to write $t-mon-1?
$t-year # based at 0 (year 0 AD is, of course 1 BC).
$t-_year # year minus 1900
What would year minus 1900 be good for?
$t-wday # based at 1 = Sunday
$t-_wday # based at 0 = Sunday
Same here.
$t-hms # 01:23:45
AM or PM? Or 24h clock?
And why is the hour padded with a leading zero, while that is not the
case with the $hour value in list and other contexts.
$t-ymd # 2000/02/29
$t-mdy # 02/29/2000
$t-dmy # 29/02/2000
Hmm. A lot of duplicate information. And how about
$t-hms # 01:02:33
Wouldn't it be better to have a formatting method, like
$t-format("%m/%d/%Y")# 29/02/2000
$t-format# uses preset format, same as "$t"
and rename your $t-format to $t-set_format?
$t-isutc # in UTC time?
$t-tz# timezone (also $t-timezone)
Again, 'isutc' looks superfluous to me.
But I would like to have 'tzsec' (the #seconds displacement for this
timezone).
The C$tz variable might seem hard at first. It's not. There are only 2
possible values:
1. UTC or other timezone (user specified)
2. Local timezone (none specified)
So, all that would have to happen is Cdate() would have to store the
correct value in the return object, in the precendence above.
Huh? If the user specifies 'PST' you have to _know_ what 'PST' means.
-- Johan
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
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 sort the dates to whatever accuracy you want by comparing each of the first n elements in turn for some value of n defined bu the accuracy you want. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ...If we left the bones out it wouldn't be crunchy.
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
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 timezone. # Access UTC information $scalar = date time, '%H:%M', 'UTC'; # return time in UTC $object = date time, undef, 'GMT';# return object in UTC # Explicity get ctime date for Eastern US time # If $time is undef, time() is assumed $scalar = date undef, undef, 'EST'; 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* standardized and are quite frequently ambiguous. There are three other prevelant time-zone naming schemes: the POSIX one (EST5EDT, for example) is completely insufficient to actually represent time zone variations as they occur in the real world, the "old Olson" found in most Unix operating systems these days with names like US/Pacific doesn't offer enough granularity, and the "new Olson" method (the best of the lot) uses names that most people don't know (America/Los_Angeles for US Pacific for example). Basically, you don't want to go anywhere near this mess; it eats people. I see two reasonable options to go with instead. One is to just use a binary flag that says use UTC or not; this is the simplest and most reliable to explain. The other is to allow a timezone offset; this doesn't deal with daylight savings time and historic time zone changes, but it provides enough power for most of what people want to do and if you want to deal with the rest you have to deal with time zone naming. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
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 was thinking much the same. It also means you can sort the
dates to whatever accuracy you want by comparing each of the
first n elements in turn for some value of n defined bu the
accuracy you want.
I agree on the order but if its done right you should not have to
do a element by element comparison. You simply need to create a
date() object with your comparison date in it and overload the
and operators so that you can do
if ( $date1 $date2 ) {
...
}
On a related point, since the 0 indexed parts of local time were there
specifically for easy access into an array to retrieve the string form
would there be a method to return the month name directly without having
to do an explicit lookup (I imagine the format() part will handle this).
Is the intention to allow the stringification to know about different
languages?
Also, I would vote for a method to return the Julian date (yes I am an
astronomer...) :-)
--
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
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 as
seconds of offset. I'll put this in.
GMT is not UTC (although it is equal for most practical purposes).
Ok, I'll have to research this a little. I've heard both ways (it is, it
isn't, it's supposed to be...)
$hour = 0 .. 24
$min = 00 .. 59 # 0-padded
$sec = 00 .. 59 # 0-padded
Why 0-padding? The only reason to add this is out of frustration due
to localtime's behavior. With the new date function you'll never need
to call
sprintf("%02d/%02d/%04d", $tm[3], $tm[4]+1, $tm[5]+1900);
since you can do
date(undef,"%d/%m/%Y")
True, but notice that you have to specify a format. You might not want a
format, but just a constant-length date/time suffix for your backup
files:
$backup_suffix = join '', ((date)[0..6]);
This is why I think 0-padding is invaluable. Granted, the same thing
could be done with a format, but the above would probably be quicker.
Plus, I don't see the 0-padding as having any negative side-effects
(remember, localtime() will still be in Time::Local).
Also, why not space-pad the mday?
Actually, given what I just said above - good point! This is actually a
whole issue by itself. Here's the question: how should day/month/year
look:
02/05/0982# 0-padded
2/5/982 # not 0-padded
Geez, I can really see it both ways (although I probably prefer the
former because it's easier to work with).
Isn't $isutc identical to ($tz eq 'UTC')?
Yes. The difference is that it makes comparisons much cleaner:
if ($isutc) { ... }
if ($date-isutc) { ... }
And since we already have one for $isdst, I figured it was useful.
However, if there's a lot of counter-opinion, it can be removed.
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.
Sounds good, I agree. It actually makes things much more usable too.
$t-mon # based at 1
$t-_mon # based at 0
Why? Is it so hard to write $t-mon-1?
All the examples you mention are actually requests from Larry himself.
Check out the link I mentioned at the bottom of the RFC.
That being said, if we don't like them, we can remove them still. I
intentionally only left them accessible via the object form, but I think
they are pretty useful actually (they give you access to localtime()
formatted stuff). We might want to change the names a little.
Wouldn't it be better to have a formatting method, like
$t-format("%m/%d/%Y")# 29/02/2000
$t-format# uses preset format, same as "$t"
Well, this one took a lot of thinking. I actually spent a good day just
on this. Here's the issue: we need to be able to get the format given to
date() into both the object and the scalar. Setting the format with a
function that doesn't print something out seemed the right thing to do.
So, follow the call (which assumes you've read an RFC I just submitted
which hasn't been published yet :-):
$date = date undef, '%m/%d/%Y'; # puts format into $date-format(),
# returning a date() object
print "$date"; # calls $date-SCALAR, which is
# a reference to $date-date(),
# which relies on $date-format()
# ... time passes ...
$file = "$filename.$date"; # same thing again
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"; # without touching this
I'll put strftime() back in, I think that's probably the best thing for
this.
But I would like to have 'tzsec' (the #seconds displacement for this
timezone).
It's in there:
$t-tzoffset # timezone offset in seconds
Huh? If the user specifies 'PST' you have to _know_ what 'PST' means.
Right, I wasn't sure how to say this. All I meant was *maintaining* it
might be tricky. But it's not. I'll just take this part out.
-Nate
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
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 measurements the
platform doesn't support.
Or maybe a fractional second, drop the smaller fields, and include a
resolution field that would tell you how many digits are valid?
printf "%.${digits}f", $sec;
perhaps?
--Gisle
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
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 accessor functions (new)
The new Cdate() function will return time adjusted for the local
timezone. To get UTC (or GMT, for nostalgic types) time, you simply pass
an argument to Cdate().
Please don't gloss over the timezone issue so easily. There is
nothing simple about timezones (except for GMT, of course). The
reason there are *NO* good OO date modules on CPAN is that people fail
to realize what nastiness comes from sticking in timezone support as
an afterthought.
For example, Time::Object's interface practically precludes adjusting
for daylight savings when doing date (as opposed to date/time)
arithmetic:
#!/usr/local/bin/perl -w
$ENV{'TZ'} = 'US/Pacific';
use Time::Object;
use Time::Seconds;
print "$Time::Object::VERSION\n";
$t = localtime 954547200;
print $t, "\n";
print $t - 30 * ONE_DAY, "\n";
print $t + 30 * ONE_DAY, "\n";
=
add
0.11
Fri Mar 31 16:00:00 2000
Wed Mar 1 16:00:00 2000
Sun Apr 30 17:00:00 2000
Notice that adding 30 days to March 31 has the (probably unwanted)
effect of changing the time from 16:00 to 17:00. Dates and date/times
are just entirely different beasties due to the horrible (and
senseless, btw) complexity of daylight savings time rules.
-John
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
Yes! Yes! How about using a float (fractional second) instead of $msec, $nsec. Works for me (it's for you anyways). ;-) -Nate
RFC 48 (v1) Replace localtime() and gmtime() with da
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] Number: 48 =head1 ABSTRACT Currently, Perl uses the C library Clocaltime() and Cgmtime() functions for date access. However, because of many problems, these should be replaced with a single new functions, Cdate(), that will be called as follows: $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 accessor functions (new) The new Cdate() function will return time adjusted for the local timezone. To get UTC (or GMT, for nostalgic types) time, you simply pass an argument to Cdate(). =head1 DESCRIPTION =head2 Overview In the past, Perl has provided access to date and time information through the C library Clocaltime() and Cgmtime() functions. Unfortunately, these functions have several "really bad things" about them: 1. some values are 0-indexed while others are 1-indexed 2. they return massive lists as their only interface 3. minute and second values aren't 0-padded 4. the year has to have 1900 added to it to be correct. While some of these are perhaps understandable, that last one just plain doesn't make Iany sense. With Perl 6 we have the chance to fix this. While some have suggested merely changing what Clocaltime() and Cgmtime() return, this is a bad idea because: 1. Many Perl scripts already use it 2. Many C programmers are familiar with its stupidity As such, we should replace these functions with versions that work the way that we want them to. The new names will indicate that these are "not the same old time functions", and that you'd better read the docs. =head2 Proposed Syntax The new function would have several different, highly-flexible calling forms. In addition, it allows full-featured date arithmetic (currently this requires Time::Object, Date::Calc, or some other module). The new syntax of Cdate() is proposed as: $|@|%return = date [ $time ], [ $format ], [ $timezone ]; If C$time is not specified, then the current return value from Ctime() is used (just like Clocaltime()). The optional C$format affects the format of the date returned. Actually, what it does is call the object function Cformat() with the format, which in turn determines what calls to the Cdate() member function look like. See below. The C$format specifier is the same one used in CPOSIX strftime(), allowing complete date formatting with having to import the CPOSIX module. 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 timezone. Depending on the context within which Cdate() is called, many different things are returned: # Get some various local date stuff $scalar = date;# scalar ctime date, same as now $scalar = date time, '%m/%d/%Y'; # scalar date per strftime @array = date;# array of date/time values %hash= date;# hash of values (%Y is ignored!) $object = date $time; # object with accessor functions, # relative to time $time # Access UTC information $scalar = date time, '%H:%M', 'UTC'; # return time in UTC $object = date time, undef, 'GMT';# return object in UTC # Explicity get ctime date for Eastern US time # If $time is undef, time() is assumed $scalar = date undef, undef, 'EST'; =head2 Alternate Syntax The initial syntax I was going to propose would involve two functions: date [ $time ], [ $format ] utcdate [ $time ], [ $format ] This is similar to above, only there are two possible timezones and therefore no timezone argument. Everything else remains the same as the specification above. I chose to use 'utc' instead of 'gmt' because it's time to catch up with standards (and "UTC" is the "official" name of univeral time). I abandoned this in favor of the more flexible single Cdate() function (which gives you access to any timezone). However, it may be more appropriate to use these two separate functions. =head2 Return Values The return values are dependent on the context within which Cdate() is called. For all contexts, the following are the values and their ranges: $hour = 0 .. 24 $min = 00 .. 59 # 0-padded $sec = 00 .. 59 # 0-padded $msec = 0 .. 999 $nsec = 0 .. 10**9 # nanoseconds, unless Gisle needs more! :-) $mon = 1 .. 12# hooray! $mday = 1 .. 31 $year = 1 .. # 4-digit! $wday = 1 .. 7 # 1 ==
