Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>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
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 ca
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
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
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 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 thi
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 technica
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 c
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 GM
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 so
> I think this is a bit heavy-weight for core.
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.
I wish it could happen, but too many people have brought up
John Tobey <[EMAIL PROTECTED]> writes:
> On Tue, Aug 08, 2000 at 10:47:10PM -0700, Russ Allbery wrote:
>> 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 entri
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
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 p
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 off
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 th
> 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?
Not necessarily. But I think most people agree we should decide on one
interface. If we stuck to this, we'd have to move lo
> "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
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 you
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.
Well, I guess we all want something a little different.
I, for example, want a
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 t
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 localti
> 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 so
> 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 reasona
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 us
25 matches
Mail list logo
