On Aug 17, 2005, at 00:29 , Larry Wall wrote:
which gives us these possibilities.
大務big / (perform) duty
Perl6 to people here.
太夢fat, big / dream
Perl6 for the rest of us.
対夢oppose, against, pair / dream
Pugs?
待夢wait / dream
Perl6 to Oreilly ?
滞
Well, right now one of the great things about looking at the wall to
read the clock and see the time, is that you know that based on the time
of day and the time of year, and where you are, roughly how far through
the actual solar day it is. It's crude, but useful. Just ask a Dairy
Farmer.
Do
On Wed, 2005-08-17 at 01:28 -0500, Dave Rolsky wrote:
> > Why on earth would you want to encourage such a short sighted
> > programming practise? The earth wobbles like a spinning top. In fact
> It's hardly short sighted to want leap seconds to be abandoned (not in
> Perl but world wide). The f
On Wed, 17 Aug 2005, Sam Vilain wrote:
Why on earth would you want to encourage such a short sighted
programming practise? The earth wobbles like a spinning top. In fact
It's hardly short sighted to want leap seconds to be abandoned (not in
Perl but world wide). The few people who _really_
On Mon, 2005-08-15 at 22:24 -0700, Larry Wall wrote:
> : > That's my leaning--if I thought it might encourage the abandonment of
> : > civil leap seconds, I'd be glad to nail it to Jan 1, 2000, 00:00:00.0 UTC.
> : If we're going with TAI, can't we just nail it to the epoch it defines,
> : instead?
On Tue, Aug 16, 2005 at 01:18:40PM -0400, Mark Reed wrote:
: More generally, the numbers are quite reasonable. For example, for about 30
: years on either side of the epoch you have resolution to at least .1
: microsecond.
And in 30 years we'll probably mostly be using 128 or 256-bit floaters...
On 2005-08-16 12:39, "Brano Tich‡" <[EMAIL PROTECTED]> wrote:
> A related question:
> I think it was stated, that the time will be some floating-point number.
> Will its precision be predetermined or will it be system-dependent?
> (Or maybe the precision is no-issue -- it could be important in comp
I vote for double-precision floating-point. Since double precision
is good to 10^-15, that allows times to be specified to a precision
of about 3 microseconds for the next century, and to a precision of
30 microseconds for the next millennium. Anyone who wants more
precision than that is l
A related question:
I think it was stated, that the time will be some floating-point number.
Will its precision be predetermined or will it be system-dependent?
(Or maybe the precision is no-issue -- it could be important in comparisons,
but one can argue one should always specify the smallest
On Wed, 17 Aug 2005, Autrijus Tang wrote:
...This seems to be quite consistent with the rumoured US proposal to
abolish leap seconds by adding leap hours every 500 years or so:
Wow, a piece of US government policy I can actually support! Hell must be
a cold place right now.
-dave
/*=
On Tue, Aug 16, 2005 at 08:37:24AM -0700, Larry Wall wrote:
> : But that's in contrast to your saying that the epoch would be December 31,
> : 1999 at 23:59:29.0 UTC. Or did I misread your earlier messages?
>
> Yes, you misread it. I was angling for 00:00:00.0 UTC. But it scarcely
> matters if
into some higher-level
representation, like a date(time) object.
The existing Time::Local bits in pugs are a reasonable start at a simple
lightweight datetime class, and I'm hoping to be able to provide a more
complete set of classes for date & time bits in the future. If we can
encoura
Hmmm... at least backwards leap-seconds are fixed. Handling leap-
seconds for all time requires net access or frequent software
updates, but a single block of 32 comparisons handles everything up
to A.D. 2000.
On Aug 16, 2005, at 9:24 AM, Dave Rolsky wrote:
On Mon, 15 Aug 2005, Larry Wa
On Tue, Aug 16, 2005 at 10:24:41AM -0500, Dave Rolsky wrote:
: On Mon, 15 Aug 2005, Larry Wall wrote:
:
: >But the best part is that if we abandon UTC leap seconds for civil time,
: >we don't have to remember leap seconds going forward, only backward from
: >2000.
:
: So you want to take on the (
On Mon, Aug 15, 2005 at 09:21:14PM -0400, Jasmine Pues wrote:
: Taimu? TAI- -mu.
:
: Sorry. Couldn't resist the pun. (Bad Japanese pun, but nonetheless.)
Well, hmm, yes, "taimu" means "time" in Japanese, but only because it's
borrowed... ☺
On the other hand, if you're willing to coin a new Japa
On Mon, 15 Aug 2005, Larry Wall wrote:
But the best part is that if we abandon UTC leap seconds for civil time,
we don't have to remember leap seconds going forward, only backward from
2000.
So you want to take on the (very irritating, I tell you) burden of leap
seconds going _backwards_ but
Taimu? TAI- -mu.
Sorry. Couldn't resist the pun. (Bad Japanese pun, but nonetheless.)
-Jasmine
2005/8/15, Sam Vilain <[EMAIL PROTECTED]>:
> On Mon, 2005-08-15 at 16:33 -0700, Larry Wall wrote:
> > : I would assume that you would choose time 0.0 = Jan 1, 2000 at 00:00:00.0
> > : TAI (December 3
On Tue, Aug 16, 2005 at 01:18:58PM +1200, Sam Vilain wrote:
: On Mon, 2005-08-15 at 16:33 -0700, Larry Wall wrote:
: > : I would assume that you would choose time 0.0 = Jan 1, 2000 at 00:00:00.0
: > : TAI (December 31, 1999 at 23:59:29.0 UTC), making the whole thing free of
: > : any UTC interfere
On Mon, 2005-08-15 at 16:33 -0700, Larry Wall wrote:
> : I would assume that you would choose time 0.0 = Jan 1, 2000 at 00:00:00.0
> : TAI (December 31, 1999 at 23:59:29.0 UTC), making the whole thing free of
> : any UTC interferences. But there is an argument for making the zero point a
> : reco
On Mon, Aug 15, 2005 at 04:41:03PM -0400, Mark Reed wrote:
: On 2005-08-15 13:56, "Larry Wall" <[EMAIL PROTECTED]> wrote:
: > Perl 6 will natively think of dates as number of floating point TAI
: > seconds from the year 2000. You can build any kind of date interface
: > on top of that, but we're g
On 2005-08-15 13:56, "Larry Wall" <[EMAIL PROTECTED]> wrote:
> Perl 6 will natively think of dates as number of floating point TAI
> seconds from the year 2000. You can build any kind of date interface
> on top of that, but we're going for simplicity and predictability.
I applaud that decision.
On 2005-08-15 13:56, "Larry Wall" <[EMAIL PROTECTED]> wrote:
> I'm personally rooting for everyone to abandon leap seconds for civil time.
While you're at it, why not wish for DST to go away (or to become permanent
year-round, whichever)? Heck, toss in world peace, too. :)
> But POSIX stretchy s
On 2005-08-15 15:04, "Doug McNutt" <[EMAIL PROTECTED]> wrote:
> At 13:31 -0400 8/15/05, Mark Reed wrote:
> If anyone gets serious about Julian dates there is also the Modified Julian
> Date, MJD, used by the US military and others. It differs from the JAD above
> by a large well-defined integer p
Perl 6 will natively think of dates as number of floating point TAI
seconds from the year 2000. You can build any kind of date interface
on top of that, but we're going for simplicity and predictability.
If UTC goes ahead with with additional leap seconds, we will NOT use
Posix stretchy seconds t
At 13:31 -0400 8/15/05, Mark Reed wrote:
>More specifically, that's the astronomical Julian Day, or JD, and JD 0 began
>at noon Universal Time (a.k.a. GMT) on January 1, 4713 BC in the Julian
>calendar. Sometimes this is called the Julian Astronomical Day, or JAD, to
>distinguish it from various o
On 2005-08-15 13:07, "Mark A. Biggar" <[EMAIL PROTECTED]> wrote:
> 3) use Astronomical Dates which are kept as the number of days sense
> noon Jan-1-4713 BC.
More specifically, that's the astronomical Julian Day, or JD, and JD 0 began
at noon Universal Time (a.k.a. GMT) on January 1, 4713 BC in th
Nicholas Clark wrote:
On Tue, Jul 05, 2005 at 06:47:41PM -0600, zowie wrote:
There is also a certain joy that comes from noticing that a tool was
designed by pedants:
it's great that cal(1) handles the Gregorian reformation correctly
(or at least, in one
of several arguably correct ways) ev
On 2005-08-15 10:07, "Nicholas Clark" <[EMAIL PROTECTED]> wrote:
> Spain adopted the Gregorian Calendar in 1582. Surely setting my locale to
> Spain should make the Julian/Gregorian jump show up in 1582, not 1752?
Arguably so, but I don't think there's anywhere in the POSIX localization
data struc
On Tue, Jul 05, 2005 at 06:47:41PM -0600, zowie wrote:
> There is also a certain joy that comes from noticing that a tool was
> designed by pedants:
> it's great that cal(1) handles the Gregorian reformation correctly
> (or at least, in one
> of several arguably correct ways) even though most
On Wed, 6 Jul 2005, Juerd wrote:
I think the problem one has is much bigger even if a day *number* is
ever displayed. Then beginning with 1 because that's where most humans
begin counting, is wrong. It's a technical thing, and that should be
kept as simple as possible, and as technical as possib
Juerd wrote:
I think the problem one has is much bigger even if a day *number* is
ever displayed. Then beginning with 1 because that's where most humans
begin counting, is wrong. It's a technical thing, and that should be
kept as simple as possible, and as technical as possible, for easier
compat
On Tue, Jul 05, 2005 at 03:48:47PM -0700, Dave Whipp wrote:
: Dave Whipp wrote:
:
: >You can use "{time - $epoch}" or "{time.as<%d>}" or "{int time}". (That
: >last one is not "{+time}", because that would be a floating-point value,
: >not an integer).
Or {time.int}, presumably.
: I was thinki
On Tue, Jul 05, 2005 at 06:47:41PM -0600, zowie wrote:
: Hmmm Actually, ntpd achieves that sort of accuracy -- but if
: I understand correctly it anchors the UTC time to the standard,
: and allows the UNIX seconds count (which often does not account for
: new leap seconds, though some gmtime v
On Jul 5, 2005, at 6:18 PM, Sam Vilain wrote:
Craig DeForest wrote:
Using the TAI epoch of 1958-01-01 00:00:00 has several advantages:
- TAI is recognized by international standards-setting bodies
(BIPM).
- Perl6 will then shake out the 31-bit time rollover a full 12
years before
Craig DeForest wrote:
Using the TAI epoch of 1958-01-01 00:00:00 has several advantages:
- TAI is recognized by international standards-setting bodies (BIPM).
- Perl6 will then shake out the 31-bit time rollover a full 12 years before
I like this in principle, however I wonder of the
Dave Rolsky skribis 2005-07-05 15:41 (-0500):
> As for 0 vs 1 as the index, I think this is a bit of a red herring. If
> you're constantly using this as an array index you're operating at too low
> a level (IMO). If all your programs start with:
> my @DayNames = qw( Sunday Monday Tuesday ... )
On Tue, 5 Jul 2005, Juerd wrote:
No. Humans don't USE numbers for week days! So beginning at 1 makes no
sense, except for humans who like creating lists like (undef, ). In fact, I would prefer to
not having any 0 :)
This should be separated into day() and day_name(). It's hardly obvious
tha
Darren Duncan wrote:
Actually, there was a big oversight in my last message. It does not
handle approximate or relative dates, such as when you don't know the
details.
FWIW, this is handled by DateTime::Incomplete, and also will be natively
supported by Date::Gregorian.
You're describing wit
At 3:36 PM -0700 7/5/05, Dave Whipp wrote:
Darren Duncan wrote:
The object should not store anything other than this single
numerical value internally (smart caching of conversions aside).
I think we can all either agree with that, or dont-care it. The
internal implementation is an implementa
Quoth Craig DeForest on Tuesday 05 July 2005 04:59 pm,
> ...This is important
> because, without proper maintenance of the leap-second table, all of our
> perl6 calendar programs will run an hour late a mere 500 years from now.
Uh, sorry -- "...an hour fast a mere 500 years from now."
Quoth Darren Duncan on Tuesday 05 July 2005 04:20 pm,
> I believe that at its core [the time/date] object should simply store a
count of
> rigorously defined time units relative to a rigorously defined epoch.
> What the epoch is and what the time unit is will need to be
> officially defined (eg,
Actually, there was a big oversight in my last message. It does not
handle approximate or relative dates, such as when you don't know the
details.
My previous proposal should be restricted specifically to the
situations where you know the date/time to a high precision, to the
second. So my
Dave Whipp wrote:
You can use "{time - $epoch}" or "{time.as<%d>}" or "{int time}". (That
last one is not "{+time}", because that would be a floating-point value,
not an integer).
I was thinking: an epoch is just a time, and "int time" is a duration --
the number of seconds since the current
Darren Duncan wrote:
The object
should not store anything other than this single numerical value
internally (smart caching of conversions aside).
I think we can all either agree with that, or dont-care it. The internal
implementation is an implementation issue (or library). It doesn't need
t
All,
In the spirit of forward thinking and adaptability (and
internationalization), I believe a core Time/Date object should be
calendar agnostic and simply store some value that is easily
convertable to any date + time on any calendaring system. I say
forward thinking because this system wi
Douglas P. McNutt wrote:
At 10:55 -0700 7/5/05, Dave Whipp wrote:
I don't understand why time() should return a numeric value at all.
Some of us like to use epoch time, as an integer, to create unique file names which sort
"right" in a shell or GUI.
You can use "{time - $epoch}" or "{time
At 10:55 -0700 7/5/05, Dave Whipp wrote:
>I don't understand why time() should return a numeric value at all.
Some of us like to use epoch time, as an integer, to create unique file names
which sort "right" in a shell or GUI.
--
--> From the U S of A, the only socialist country that refuses to
Hi,
Juerd wrote:
> Ingo Blechschmidt skribis 2005-07-05 20:08 (+0200):
>> FWIW, I agree, but I'd like to propose standard overloadings:
>> say ~$time; # "Di 05 Jul 2005 20:01:42 CEST"
>
> Or perhaps not. In fact, rather not. Please let stringification be the
> ISO standard, and otherwis
Dave Rolsky skribis 2005-07-05 11:41 (-0500):
> >* .month and .wday are one-based. Sunday == 1. Haskell has them as
> > enums which avoids off-by one confusion completely; I made them like
> > I did because that's like humans think of them.
> And yes again!
No. Humans don't USE numbers for week
Ingo Blechschmidt skribis 2005-07-05 20:08 (+0200):
> FWIW, I agree, but I'd like to propose standard overloadings:
> say ~$time; # "Di 05 Jul 2005 20:01:42 CEST"
Or perhaps not. In fact, rather not. Please let stringification be the
ISO standard, and otherwise certainly sortable: year f
Hi,
Dave Whipp wrote:
> Larry Wall wrote:
>> The time function always returns the time in floating point.
>
> I don't understand why time() should return a numeric value at all.
> Surely it should return a DateTime (or Time) object. Using epochs in a
> high level language seems like a really bad
Larry Wall wrote:
The time function always returns the time in floating point.
I don't understand why time() should return a numeric value at all.
Surely it should return a DateTime (or Time) object. Using epochs in a
high level language seems like a really bad thing to be doing. If I want
On Tue, 5 Jul 2005, Gaal Yahas wrote:
Regarding Time::Local fields, it's an object now, so the order of things
Should that be Time::localtime? In P5 there are Time::localtime &
Time::gmtime, which are thin OO facades over the language builtins. Then
there's the module Time
On Tue, Jul 05, 2005 at 11:41:23AM -0500, Dave Rolsky wrote:
> >Regarding Time::Local fields, it's an object now, so the order of things
>
> Should that be Time::localtime? In P5 there are Time::localtime &
> Time::gmtime, which are thin OO facades over the language bu
On Tue, Jul 05, 2005 at 08:16:54AM -0700, Larry Wall wrote:
> I don't think either of those are good human engineering. I would
> like the preferred Perl 6 form to simply be:
>
> multi sub localtime(Num $?when = time) returns Time::Local { ... }
Done.
I take it that the re
On Tue, Jul 05, 2005 at 04:39:48PM +0300, Gaal Yahas wrote:
: As for the function signatures:
:
:multi sub localtime(Rat $?when = time) returns Time::Local { ... }
:multi sub localtime(Int $sec, Int ?$pico = 0) returns Time::Local {...}
:
: The first form uses the second, but might be
update S29 if I am not.
Regarding Time::Local fields, it's an object now, so the order of things
matters less now than it did in p5. The fields I've made available
naturally follow GHC's CalendarTime type[1]. The important deviations
from p5 are:
* .year is the Gregorian year, n
57 matches
Mail list logo
