Time::Local

16 views
Skip to first unread message

Gaal Yahas

unread,
Jul 5, 2005, 9:39:48 AM7/5/05
to perl6-l...@perl.org, aut...@urth.org
I've added localtime to pugs (r5233, 5236), to address Dave Rolsky's needs
for DateTime; but I'm noticing S29 doesn't spec this and nearby builtins
yet. I'd like to raise the questions I encountered / stipulations I've
made. Please let me know if I'm in error or 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, no 1900 offeset or anything like that.

(Haskell doesn't promise accuracy in the readable version of
pre-Gregorian dates, which I think is okay for us as well, as long
as the opaque internal representation remains consistent. That's part
of where libraries such as DateTime can help.)

* .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.

* .picoseconds - we don't promise this granularity is available by the
system, but I don't suppose we'll ever need anything finer than that
:-)

* Once we sort out context and want in pugs, I can return a List when
one is expected, instead of an object. Then the order of fields
becomes important and I'm inclined to go with year first, like the
Haskell module, so that least significant things come last. This is the
reverse of p5 Time::Local. When timelocal and timegm are implemented,
they will of course use whatever order their inverses use.

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 less precise.

[1] http://haskell.org/ghc/docs/latest/html/libraries/base/System.Time.html#t%3ACalendarTime

--
Gaal Yahas <ga...@forum2.org>
http://gaal.livejournal.com/

Larry Wall

unread,
Jul 5, 2005, 11:16:54 AM7/5/05
to perl6-l...@perl.org
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 less precise.

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 { ... }

The time function always returns the time in floating point. In fact,
all numeric times are Num in Perl 6. Then you don't have to worry
about whether picosecond resolution is good enough. Time and
duration objects can, of course, do whatever they like internally,
and among themselves, but someone who says sleep($PI) should get a
$PI second sleep. Our computers are capable of floating point these
days, and I consider any other numeric time format to be cultural
baggage. I particularly loathe any kind of two integer format.

Sorry about the rant, but you seem to have pushed one of my hot buttons...

Larry

Gaal Yahas

unread,
Jul 5, 2005, 12:28:25 PM7/5/05
to perl6-l...@perl.org
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 rest is okay? If so I'll submit a doc patch to S29.

Gaal Yahas

unread,
Jul 5, 2005, 1:23:44 PM7/5/05
to Dave Rolsky, perl6-l...@perl.org
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 builtins. Then
> there's the module Time::Local, which is entirely different.

Hmm, I agree. I used Time::Local because that's what the draft Synopsis
put them in, but Time is a better fit.

> All of those provide useful functionality, and probably Time::Local should
> be part of the language, _or_ localtime & gmtime should be in a library.

Not my call, but I think we can add timelocal and timegm soon. They're
mostly cleverly-caching facades to Time.new anyway, no? Drop by on #perl6
if you want to hack on the Prelude side of this.

Dave Rolsky

unread,
Jul 5, 2005, 12:41:23 PM7/5/05
to Gaal Yahas, perl6-l...@perl.org
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::Local, which is entirely different.

All of those provide useful functionality, and probably Time::Local should

be part of the language, _or_ localtime & gmtime should be in a library.

> * .year is the Gregorian year, no 1900 offeset or anything like that.

Yes!

> * .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!

> * .picoseconds - we don't promise this granularity is available by the
> system, but I don't suppose we'll ever need anything finer than that
> :-)

The more granularity the better, really. DateTime right now supports
nanoseconds, which was a semi-arbitrary choice that seemed granular
enough. Picoseconds is even better. Anyone who needs more probably has
some sort of special hardware providing their data anyway, and will need a
special interface to it (hand waving).

> * Once we sort out context and want in pugs, I can return a List when
> one is expected, instead of an object. Then the order of fields
> becomes important and I'm inclined to go with year first, like the
> Haskell module, so that least significant things come last. This is the
> reverse of p5 Time::Local. When timelocal and timegm are implemented,
> they will of course use whatever order their inverses use.

I'd agree that this makes the most sense.


-dave

/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/

Dave Whipp

unread,
Jul 5, 2005, 1:55:14 PM7/5/05
to perl6-l...@perl.org
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
"duration since epoch" then I should subtract the epoch from the time --
resulting in a duration (which may indeed be a floating point value).

my DateTime $epoch is constant = DateTime "2000-01-01 00:00:00";
my Num $seconds_since_epoch = time - $epoch;


> In fact,
> all numeric times are Num in Perl 6. Then you don't have to worry
> about whether picosecond resolution is good enough. Time and
> duration objects can, of course, do whatever they like internally,
> and among themselves, but someone who says sleep($PI) should get a
> $PI second sleep.

For the sleep function, it seems reasonable to accept either a DateTime
or a Duration, which would sleep either until the requested time, or for
the requested duration.

> Sorry about the rant, but you seem to have pushed one of my hot buttons...

Ditto

> Larry

Juerd

unread,
Jul 5, 2005, 2:17:09 PM7/5/05
to Ingo Blechschmidt, perl6-l...@perl.org
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 first, then month,
then mday.

2005-07-05T20:01:42+0200


Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html

Ingo Blechschmidt

unread,
Jul 5, 2005, 2:08:33 PM7/5/05
to perl6-l...@perl.org
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 thing to be doing. If I
> want "duration since epoch" then I should subtract the epoch from the
> time -- resulting in a duration (which may indeed be a floating point
> value).

FWIW, I agree, but I'd like to propose standard overloadings:
my $time = time; # some kind of Date/Time object


say ~$time; # "Di 05 Jul 2005 20:01:42 CEST"

say +$time; # seconds since the Perl 6 epoch
# (2000-01-01 according to [1])

> For the sleep function, it seems reasonable to accept either a
> DateTime or a Duration,

or a number of seconds,

> which would sleep either until the requested time, or for the
> requested duration.


--Ingo

[1]
http://groups.google.de/group/perl.perl6.internals/msg/a572113dc089481b

--
Linux, the choice of a GNU | Elliptic paraboloids for sale.
generation on a dual AMD |
Athlon! |

Ingo Blechschmidt

unread,
Jul 5, 2005, 2:33:43 PM7/5/05
to perl6-l...@perl.org
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 otherwise certainly sortable: year first, then
> month, then mday.
>
> 2005-07-05T20:01:42+0200

WRT to sorting: The Date/Time/whatever class should overload
&infix:«<=>», so sorting really works -- if you sort those ISO strings,
you'll probably get wrong results, as the timezone diff isn't taken
into account.

I don't have a strong opinion on the default format of the
stringification.

Could/should we use .as for this, to leave the choice to the programmer?

say time.as("%H:%M:%S"); # 20:26:36

Note though that it's inconsistent:
say "hi".as("%H:%M:%S"); # error
say time.as("%H:%M:%S"); # works


--Ingo

--
Linux, the choice of a GNU | "The future is here. It's just not widely
generation on a dual AMD | distributed yet." -- William Gibson
Athlon! |

Juerd

unread,
Jul 5, 2005, 2:22:07 PM7/5/05
to Dave Rolsky, Gaal Yahas, perl6-l...@perl.org
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 days! So beginning at 1 makes no
sense, except for humans who like creating lists like (undef, <Sunday
Monday ...>). In fact, I would prefer <Saturday Sunday Monday ...> to
not having any 0 :)

Now, for months, yes it does make lots of sense.

Dave Whipp

unread,
Jul 5, 2005, 4:39:09 PM7/5/05
to perl6-l...@perl.org
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.as<%d>}" or "{int time}". (That
last one is not "{+time}", because that would be a floating-point value,
not an integer).

Douglas P. McNutt

unread,
Jul 5, 2005, 4:31:19 PM7/5/05
to perl6-l...@perl.org
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 admit it. <--

Darren Duncan

unread,
Jul 5, 2005, 6:20:31 PM7/5/05
to perl6-l...@perl.org
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 will be forwards compatible with
calendaring systems that don't yet exist, and backwards compatible
with older calendars we haven't bothered to account for yet.

I believe that at its core said 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, Jan 1, 2000; counting in fractions of
seconds). The object should not store anything other than this
single numerical value internally (smart caching of conversions
aside).

Save all human-desired representations to something that is computed
on request, such as using a getter method named after the desired
format; and setting would do the reverse. This can work with values
in any calendaring system.

With this system, date calculations and storage are trivially easy,
and Perl's built-in date/time function would simply return that
number or said object. All the complexity is in the getter/setter
methods that are specific to what details a user wants, such as the
day of week or an ISO formatted string. In fact, all of that actual
conversion stuff would be what modules are good for. Perl internally
just has to know about the one number.

-- Darren Duncan

Dave Whipp

unread,
Jul 5, 2005, 6:36:16 PM7/5/05
to perl6-l...@perl.org
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
to be defined by the language. The one important thing is that that
language shouldn't define semantics that require more than this single
value (e.g. we shouldn't associate the epoch with the object).

Craig DeForest

unread,
Jul 5, 2005, 6:59:48 PM7/5/05
to perl6-l...@perl.org, Darren Duncan

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, Jan 1, 2000; counting in fractions of
> seconds). The object should not store anything other than this
> single numerical value internally (smart caching of conversions
> aside).


Agree agree...

Hmmm.... Straight seconds-counting has the flavor of international atomic
time (TAI) to it, which suggests using the TAI (rather than UNIX) epoch.

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
the rest of the UNIX-speaking world. :-)
- TAI is sufficiently different from UNIX time to make implementors think
carefully about their time conversion software. This is important because
some UNIX implementations handle leap-seconds and others don't, and this is a
nice chance to get everything Right the first time.
- TAI-to-UT conversion modules can easily ingest leap-second announcements
without further conversion to a different time base (see, e.g.,
ftp://62.161.69.5/pub/tai/publication/leaptab.txt). 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.

Dave Whipp

unread,
Jul 5, 2005, 6:48:47 PM7/5/05
to perl6-l...@perl.org
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 epoch. So, the following should
work:

for 1 .. 2 -> {
use epoch time();
sleep 6;
say int time;
}

This should print something close to "6", twice.

But something niggled me: does the value of the RHS of a "use" get
evaluated at run time, or compile time? In perl5, that could definitely
would only execute the C<use> once.

I could see 3 possible behaviors:

1. C<use> sets the epoch for each iteration of the loop, thus calling
time() one per iteration

2. C<use> executes just once, at compile time. Thus seconds iteration
prints approximately "12"

3. C<use> does a compile-time binding of the epoch to the time()
function. So each iteration prints "0".


Which actually happens?

Darren Duncan

unread,
Jul 5, 2005, 6:59:01 PM7/5/05
to perl6-l...@perl.org
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 previous proposal would still work for general tasks
where the date/time you are storing in the object is generated by a
clock, such as the computer's clock or a network time server etc, and
is perfectly appropriate for what Perl's built-in "get current
date/time" returns.

I should also clarify that when I say "rigorously defined epoch",
that also specifies a location (such as, "Jan 1, 2000, at Greenwich
(sp?)"). Any mess related to time zones would be accounted for only
during any calendar conversion used for storage or retrieval.

For the other side, where the dates are imprecise, it actually would
be useful to store them internally in calendar specific and human
terms, basically matching whatever the source was. For example, you
would store a date/time like "early May of 1743" this way; if all you
know is that the date was in "early May", then what you're storing is
fully accurate. Shoe-horning this into a specific day etc just for
storage makes the data less accurate because someone reading the
storage value presumes we knew for sure it was that day etc when in
fact we didn't. Another example of an imprecise and relative date is
"in the 4th year of Xerxes reign". If you didn't know when on our
calendar that Xerxes ruled, you can't exactly convert this to a
Gregorian calendar; you must store it in the terms that I mentioned
for highest accuracy.

Now of course, for such imprecise things, the simplest storage method
is to just use a character string. Where it gets more complicated is
if you want to do math or calculations with this imprecise info;
that's one place that date/time such modules would really be useful
and have their work cut for them.

BTW, my main programming project (unreleased) is a
genealogy/history/anything database type application, of an
unprecedented focus and feature set, so I've thought a lot about
these sorts of issues for being the most accurate and trustworthy
possible.

-- Darren Duncan

Craig DeForest

unread,
Jul 5, 2005, 7:03:28 PM7/5/05
to perl6-l...@perl.org, Darren Duncan
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."

Darren Duncan

unread,
Jul 5, 2005, 7:04:42 PM7/5/05
to perl6-l...@perl.org

What I'm saying is that the epoch for a high-precision-knowledge date
is effectively hard-coded into Perl as a "standard" and users do not
specify it or override it at any time. If this is accepted, then all
that's left to discuss for these types of dates is what list of
conversion methods there are and accepted input/output formats.
Which perhaps is the point. The main reason implementation would
have a say is if Perl's built-in functions do not return the
Date/Time object, but some scalar information instead like Perl 5.
But I say it should return the object. -- Darren Duncan

Sam Vilain

unread,
Jul 5, 2005, 7:09:50 PM7/5/05
to Darren Duncan, perl6-l...@perl.org
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 with this and other messages very much how the `Date'
distribution in pugs is being designed. I'd very much appreciate input
on that interface.

Sam.

Dave Rolsky

unread,
Jul 5, 2005, 4:41:49 PM7/5/05
to perl6-l...@perl.org
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, <Sunday
> Monday ...>). In fact, I would prefer <Saturday Sunday Monday ...> to
> not having any 0 :)

This should be separated into day() and day_name(). It's hardly obvious
that day() should return a string, much less a bit of English!

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

I think you have a bigger problem than simply adjusting for a 1-indexed
day number ;)

Juerd

unread,
Jul 5, 2005, 7:42:28 PM7/5/05
to Dave Rolsky, perl6-l...@perl.org
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 ... );
> I think you have a bigger problem than simply adjusting for a 1-indexed
> day number ;)

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
compatibility with existing technical things.

Calling Sunday 1 and not having a 0 would certainly upset and offend me.

My weeks begin on Mondays, as do most people's weeks here. At the same
time, I can accept any day as the first day if that first day is 0,
because 0 is technical and internal anyway, not meant for humans.

I'm sure lots of people would want an index 1 to be Sunday, if there is
no index 0. This all is solved simply by NOT skipping 0, and using an
arbitrarily chosen day for the first. Or, well, for compatibility,
Sunday :)

Computers and Perl count from 0. People count from 1. If something
begins at 1, it is expected to be a people's thing. And with week days,
this just doesn't work, as not everyone's week starts at the same day.

Sam Vilain

unread,
Jul 5, 2005, 8:18:37 PM7/5/05
to Craig DeForest, perl6-l...@perl.org, Darren Duncan
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 merits of professing to
return something of more accuracy than can actually ever be realistically
assured from any of the platforms Perl runs.

For a start, to convert from the available time source - the system clock
- to TAI, you need to know;

a) current adjustments, or when the lack of adjustments is considered
valid up to (after that date, of course, if the list of adjustments
is not updated, getting the time or converting from a time to a date
on a calendar is an exception).

b) whether or not the system clock is automatically correcting for
leap seconds, ie when ntpd is running and sync'ed up.

In any case, I'll add "to_TAI" as one of the marshalling methods for
Date objects in Date.pm

I guess it comes down to what guarantees we decide to make on the nature
of time(). If a leap second passes while the script is running, can the
value returned by time() regress?

In fact, do we even need a fixed epoch? Why not just free-wheel it and
make 0 the time the script started, get it to count seconds, and let
interfaces for the system clock / orson database solve the hard problems.

Sam.

Zowie

unread,
Jul 5, 2005, 8:47:41 PM7/5/05
to Sam Vilain, perl6-l...@perl.org, Darren Duncan

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


>>
> I like this in principle, however I wonder of the merits of
> professing to
> return something of more accuracy than can actually ever be
> realistically
> assured from any of the platforms Perl runs.
>

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 versions account for old ones) to drift or jump whenever
a leap
second goes by. The problem is then that interval calculations that
include the
leap second are off by one second. That probably doesn't bother most
people
but is an endless cause of hassle in scientific applications.

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 of us don't deal
with dates in 1752.

So, er, I guess I'm arguing that time/date stamps, if kept in numeric
counting-ticks form,
should follow TAI in some easily definable way, which probably means
keeping track
of leap seconds in a table that can be updated easily. Even if the
only interface most
people use is through UTC or civil time via the equivalent of gmtime
(), IWBNI the
underlying engines knew enough to work well for those people who do
care about
representing time at such high precision that leap seconds matter.
If the code is
implemented with enough care to do that right, then the natural epoch
to use is probably
1958, though as you pointed out the epoch itself is much less
important than the decision
about what kind of time to track.

Cheers,
Craig

Larry Wall

unread,
Jul 5, 2005, 9:48:46 PM7/5/05
to perl6-l...@perl.org
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 versions account for old ones)
: to drift or jump whenever a leap second goes by. The problem is
: then that interval calculations that include the leap second are off
: by one second. That probably doesn't bother most people but is an
: endless cause of hassle in scientific applications.

I think it would be wonderful to anchor our internal time to atomic
time, even if our epoch isn't 1958. It's more important for our
seconds to stay accurate than our timestamps, and we can make the
approximate interfaces do the right thing if they know they're
supposed to be approximate. The only problem is that we don't
actually have atomic time available to most of our computers right now.
Eventually we will, and I think it would be wonderful if were ready
for that transition when it happens. Maybe even to the extent of
pretending to be TAI-based by default even if we're not yet. We'll
be wrong part of the time regardless of which way we pick.

<rant>
But I really, really wish UTC hadn't decided to add a leap second
this year. It really wouldn't have hurt many folks to let midnight
drift a few seconds and then do a major seconds correction at the
end of the century, say. And it would have solved a lot of other
problems. Oh well...
</rant>

: So, er, I guess I'm arguing that time/date stamps, if kept in numeric


: counting-ticks form, should follow TAI in some easily definable way,
: which probably means keeping track of leap seconds in a table that
: can be updated easily. Even if the only interface most people use
: is through UTC or civil time via the equivalent of gmtime (), IWBNI
: the underlying engines knew enough to work well for those people
: who do care about representing time at such high precision that leap
: seconds matter. If the code is implemented with enough care to do
: that right, then the natural epoch to use is probably 1958, though
: as you pointed out the epoch itself is much less important than the
: decision about what kind of time to track.

I agree. time(2000) - time(1958) should just be a TAI constant.
(Actually, it's a constant in UTC as well--it's just the POSIXly
view of time that must die eventually. Slewing the clock for
leap seconds is Just Wrong, and someday we'll fix it. Let's design
with the assumption it will be fixed someday.)

Larry

Larry Wall

unread,
Jul 5, 2005, 10:16:25 PM7/5/05
to perl6-l...@perl.org
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 thinking: an epoch is just a time, and "int time" is a duration --

: the number of seconds since the current epoch. So, the following should
: work:
:
: for 1 .. 2 -> {
: use epoch time();
: sleep 6;
: say int time;
: }
:
: This should print something close to "6", twice.
:
: But something niggled me: does the value of the RHS of a "use" get
: evaluated at run time, or compile time? In perl5, that could definitely
: would only execute the C<use> once.

I would not necessarily assume that "use" is the best interface for
setting what is essentially a lexically scoped variable.

: I could see 3 possible behaviors:


:
: 1. C<use> sets the epoch for each iteration of the loop, thus calling
: time() one per iteration

The pragma could arrange to install something in the runtime code
at that point, but it would take extraordinary measures and be
completely unexpected.

: 2. C<use> executes just once, at compile time. Thus seconds iteration
: prints approximately "12"

Or much more than that, given separate compilation.

: 3. C<use> does a compile-time binding of the epoch to the time()

: function. So each iteration prints "0".

: Which actually happens?

Am I allowed to vote for none of the above? :-)

Actually what should happen is most like 2, I suspect.

Coming at it from a different angle, I'm thinking we should try to
get rid of built-in none-ary functions like time anyway, and parse them
to expect an argument, on the assumption that this will simplify
MMD. (In fact, that's a good reason to get rid of the entire
"named unary" precedence level and treat them all as list operators
for parsing purposes.) So if we're allowing an optional argument
to time(), then it makes sense to allow time($epoch), where time
can default to a particular epoch, or even to the epoch defined in
the caller's lexical scope. I'd like time(2000) to be the standard
default, but time(1958) shouldn't be too hard to arrange.

We could set that default pragmatically, but pragmatically speaking,
we should just set the epoch as a lexical variable that is visible
to the default value for the parameter. Then the caller can
even do something like:

temp $_epoch_ = 1970;

$x = time(); # sub time (?$epoch = $CALLER::_epoch_)

I'm not suggesting that's the proper name for the lexical variable.
In fact, we haven't got any convention for forced-lexicals in Perl
6 yet, other than, $_ and $/ are two examples of them, and $?FOO is
a compile-time lexical, and $=FOO is file-scoped in some fashion.
At one point I was thinking $*FOO would let the variable itself
decide if it was lexical or global, on the assumption that $_ is just
short for $*_. But maybe that's a Bad Idea. How do we decide which
variables are forced lexicals? More specifically, how to we request
the compiler to force other variables to be lexical, and poke them
into our lexical pads automatically for us? I think the epoch is
one of those, however we spell it. Then different modules can run
with different epochs, as long as all absolute times are passed
as objects.

Larry

Dave Rolsky

unread,
Jul 6, 2005, 12:52:09 PM7/6/05
to perl6-l...@perl.org
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 possible, for easier
> compatibility with existing technical things.
>
> Calling Sunday 1 and not having a 0 would certainly upset and offend me.
>
> My weeks begin on Mondays, as do most people's weeks here. At the same
> time, I can accept any day as the first day if that first day is 0,
> because 0 is technical and internal anyway, not meant for humans.
>
> I'm sure lots of people would want an index 1 to be Sunday, if there is
> no index 0. This all is solved simply by NOT skipping 0, and using an
> arbitrarily chosen day for the first. Or, well, for compatibility,
> Sunday :)
>
> Computers and Perl count from 0. People count from 1. If something
> begins at 1, it is expected to be a people's thing. And with week days,
> this just doesn't work, as not everyone's week starts at the same day.

On reflection, I realized it doesn't matter too much to me. In the end,
I'm likely to need a higher-level interface than this to do something
interesting (like print a day _name_ or calculate the second Sunday of the
month) and that interface will just use the information Perl's builtins
give it.

Nicholas Clark

unread,
Aug 15, 2005, 10:07:29 AM8/15/05
to zowie, Sam Vilain, perl6-l...@perl.org, Darren Duncan
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 of us don't deal
> with dates in 1752.

I disagree:


$ LC_ALL=es_ES cal 9 1752
septiembre de 1752
do lu ma mi ju vi sá
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30


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?


I think that this demonstrates how tricky all this mess is.

Nicholas Clark

Mark Reed

unread,
Aug 15, 2005, 10:44:19 AM8/15/05
to perl6-l...@perl.org
On 2005-08-15 10:07, "Nicholas Clark" <ni...@ccl4.org> 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 structures to store that information. There's a huge variety of
adoption dates, from Oct 5/15, 1582 (Most Catholic countries of Western
Europe) to March 10/23, 1924 (Greek civil usage).

Plus, even within its limited US/historical UK application, the cal(1)
program is still (admittedly so on its own man page) inaccurate for dates
prior to 1751, because it uses January 1 as the first day of the year.
While that was true in the original design of the calendar as instituted by
Caesar in 45 BC, and has been true in England and her colonies since 1751,
at some point way back when England had started counting the year change on
March 25. That was a gradual change with no clear transition date, so
matching historical practice exactly is pretty much impossible for a large
chunk of Isle history.

Mark A. Biggar

unread,
Aug 15, 2005, 1:07:57 PM8/15/05
to perl6-l...@perl.org

The actual situation is even worse. You can even use Gregorian dates
for all of 20th history as Russia didn't convert from Julian until 1920.

There is not much you can do to simply store historical dates on a computer:

1) keap all dates Gregoian even those before 1582 when the Gregorian
calendar was first used by Catholic Europe. This was right in the
middle of King Henry VIII's disagreement with the Catholic church so
England didn't convert until 1752 (the cal refernce above). Given that
Englands colonies converted at the same time this explains the confusion
over the Washington's birthday holiday where some states used Feb 11
(Julian Calendar) and some used Feb 22 (Gregorian calendar), as Feb 12
is Lincon's Birthday, for the national version of the holiday it was
decided to just call some Monday in Feb President's Day and do it all
the same day. Also, do you use a year 0 or not, which is an interesting
problem?

2) keep all dates as the people at that place and time in history would
have recorded them, but that is hard as you loose comparability and lots
of recorded historic date are Reign dated or things like N years sence
the founding of Rome, etc.

3) use Astronomical Dates which are kept as the number of days sense
noon Jan-1-4713 BC.

4) keep soe dates Julian Calandar and some Gregorian, but which switch
over do you use.

--
ma...@biggar.org
mark.a...@comcast.net

Mark Reed

unread,
Aug 15, 2005, 1:31:22 PM8/15/05
to perl6-l...@perl.org
On 2005-08-15 13:07, "Mark A. Biggar" <ma...@floorboard.com> 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 the Julian
calendar. Sometimes this is called the Julian Astronomical Day, or JAD, to
distinguish it from various other misappropriations of the term "julian
day/date".

More generally, astronomers use the Gregorian calendar like the rest of us,
but often extend it into the past before its adoption, ignoring the Julian
calendar switchover. They also tend to use 0 and negative years AD/CE in
lieu of BC(E) numbering. On that basis, JD 0 began at noon on Nov 24,
-4713.

Julian Days make a good neutral format for storing dates (and, with
fractional components, times), but they are a bit cumbersome. If you don't
actually need the range they provide (because you're only dealing with
dates near the present), it might be regarded as overkill to store the
current time as e.g. 2453598.225995. In order to get 1-second resolution,
the JD requires the same number of significant figures that's required to
get millisecond resolution with time_t.

Doug McNutt

unread,
Aug 15, 2005, 3:04:58 PM8/15/05
to perl6-l...@perl.org
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 other misappropriations of the term "julian
>day/date".

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 plus 1/2. The result is a day that begins at midnight and starts at a more recent date that I don't remember. It's not Jan 0, 1970 though.

There is also ephemeris time which is the absolute clock that makes Newtonian mechanics come out correctly regardless of changes in the rotational speed of planet Earth. Don't even think about supporting that.

--

--> Halloween == Oct 31 == Dec 25 == Christmas <--

Larry Wall

unread,
Aug 15, 2005, 1:56:59 PM8/15/05
to perl6-l...@perl.org
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 to represent them. I'm personally rooting
for everyone to abandon leap seconds for civil time. Civil leap
adjustments really ought to be scheduled more than six months in
advance. Once a century would be about right.

But POSIX stretchy seconds must die.

Larry

Mark Reed

unread,
Aug 15, 2005, 4:19:45 PM8/15/05
to perl6-l...@perl.org
On 2005-08-15 13:56, "Larry Wall" <la...@wall.org> 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 seconds must die.

So Say We All.

Mark Reed

unread,
Aug 15, 2005, 4:08:25 PM8/15/05
to Doug McNutt, perl6-l...@perl.org

On 2005-08-15 15:04, "Doug McNutt" <doug...@macnauchtan.com> 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 plus 1/2.

The (then) most recent even multiple of 100,000 was chosen for it: MJD 0 =
JD 2,400,000.5.

> The result is a day that begins at
> midnight and starts at a more recent date that I don't remember. It's not Jan
> 0, 1970 though.

November 17, 1858. Which, while not Jan 1, 1970, is still time zero for
another operating system some of you may have heard of: VMS.

There's also something called the Truncated Julian Day/Date, or TJD, which
NASA used to use: it was essentially the last four digits of the MJD, so
that TJD 0 was MJD 40000, aka May 24, 1968. But once MJD 50000 rolled
around (on Oct 10, 1995), the TJD became ambiguous. Besides, while saving a
decimal digit of storage per log entry was significant when NASA was trying
to get computers light enough to launch in the 1960s, it's not exactly an
earth-shattering storage win today. So the TJD is best avoided. In fact,
forget I mentioned it. :)


Mark Reed

unread,
Aug 15, 2005, 4:41:03 PM8/15/05
to Larry Wall, perl6-l...@perl.org
On 2005-08-15 13:56, "Larry Wall" <la...@wall.org> 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. I just have one question: will the zero point be
chosen according to TAI or UTC?

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
recognizable boundary in civil time. The Olson library does that (its zero
point is 00:00:10.0 TAI on Jan 1, 1970), but that's only because it's
designed to be a drop-in replacement for the standard POSIX library and the
time_t values have to match. Since you're changing the epoch, there's no
compatibility constraint here . . .

Larry Wall

unread,
Aug 15, 2005, 7:33:53 PM8/15/05
to perl6-l...@perl.org
On Mon, Aug 15, 2005 at 04:41:03PM -0400, Mark Reed wrote:

: On 2005-08-15 13:56, "Larry Wall" <la...@wall.org> 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. I just have one question: will the zero point be
: chosen according to TAI or UTC?
:
: 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
: recognizable boundary in civil time.

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.

Larry

Sam Vilain

unread,
Aug 15, 2005, 9:18:58 PM8/15/05
to Larry Wall, perl6-l...@perl.org
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
> : recognizable boundary in civil time.
> 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?

Sam.

Larry Wall

unread,
Aug 16, 2005, 1:24:53 AM8/16/05
to perl6-l...@perl.org
On Tue, Aug 16, 2005 at 01:18:58PM +1200, Sam Vilain wrote:

Because I'm a megalomaniac, silly dilly. Plus I like round numbers.
Not to mention the fact that it makes it really easy to calculate days
since 2000, give or take a squishy leapsecond or three.

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.

But mostly because I'm a megalomaniac, and think I can change the world.

Larry

Jasmine Pues

unread,
Aug 15, 2005, 9:21:14 PM8/15/05
to perl6-l...@perl.org
Taimu? TAI- -mu.

Sorry. Couldn't resist the pun. (Bad Japanese pun, but nonetheless.)

-Jasmine

2005/8/15, Sam Vilain <s...@vilain.net>:


--
"Don't presume to lecture me about good and evil. I've been there,
you've just seen a map."
-Orson Scott Card

--
http://www.spreadfirefox.com

Larry Wall

unread,
Aug 16, 2005, 11:37:24 AM8/16/05
to perl6-l...@perl.org
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 (very irritating, I tell you) burden of leap
: seconds going _backwards_ but not going forwards?

Well, sure, but we have no choice about the ones that were already
performed. We could certainly take on the burden of tracking leap
seconds in the future as well, but my point is we don't know them
in advance. The old ones stay put, but the new ones potentially
change from year to year. (Though they might not, if we get rid of
civil leap seconds.)

: 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 UTC keeps screwing around with leap seconds, and civil time
stays locked to UTC. I personally think we should add a bunch of leap
seconds at the beginning of every year divisible by 100, and leave the
rest of the years alone.

Larry

Dave Rolsky

unread,
Aug 16, 2005, 11:24:41 AM8/16/05
to perl6-l...@perl.org
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 not going forwards?

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?

Larry Wall

unread,
Aug 16, 2005, 11:29:19 AM8/16/05
to perl6-l...@perl.org
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 Japanese word,
we can generate all the combinations of Jouyou Kanji that can be
pronounced "TAI MU" and see what they mean together:

#!/usr/bin/perl

use utf8;
binmode STDIN, ":utf8";
binmode STDOUT, ":utf8";
binmode STDERR, ":utf8";

@tai = split /^/, <<'END';
大 big
太 fat, big
体 body; health
台 stand, platform
対 oppose, against, pair
待 wait
代 replace, world, generation, fee
帯 belt, obi, wear, zone
隊 corps, unit
退 retreat, withdraw
貸 lend, loan
態 appearance, intent
耐 endure, bear
怠 be lazy, neglect
胎 womb
泰 calm, serene, big, thai
袋 bag, pouch
逮 chase, seize
替 exchange, swap
滞 stop, stagnate
END

@mu = split /^/, <<'END';
武 military, warrior
務 (perform) duty
無 not, none, cease to be
謀 plot, strategem
矛 halberd, lance, spear
夢 dream
霧 mist, fog
END

chomp @tai;
chomp @mu;

for my $tai (@tai) {
($tk, $te) = split(' ', $tai, 2);
for my $mu (@mu) {
($mk, $me) = split(' ', $mu, 2);
printf "%s%s %s / %s\n", $tk,$mk, $te, $me;
}
}

which gives us these possibilities.

大武 big / military, warrior
大務 big / (perform) duty
大無 big / not, none, cease to be
大謀 big / plot, strategem
大矛 big / halberd, lance, spear
大夢 big / dream
大霧 big / mist, fog
太武 fat, big / military, warrior
太務 fat, big / (perform) duty
太無 fat, big / not, none, cease to be
太謀 fat, big / plot, strategem
太矛 fat, big / halberd, lance, spear
太夢 fat, big / dream
太霧 fat, big / mist, fog
体武 body; health / military, warrior
体務 body; health / (perform) duty
体無 body; health / not, none, cease to be
体謀 body; health / plot, strategem
体矛 body; health / halberd, lance, spear
体夢 body; health / dream
体霧 body; health / mist, fog
台武 stand, platform / military, warrior
台務 stand, platform / (perform) duty
台無 stand, platform / not, none, cease to be
台謀 stand, platform / plot, strategem
台矛 stand, platform / halberd, lance, spear
台夢 stand, platform / dream
台霧 stand, platform / mist, fog
対武 oppose, against, pair / military, warrior
対務 oppose, against, pair / (perform) duty
対無 oppose, against, pair / not, none, cease to be
対謀 oppose, against, pair / plot, strategem
対矛 oppose, against, pair / halberd, lance, spear
対夢 oppose, against, pair / dream
対霧 oppose, against, pair / mist, fog
待武 wait / military, warrior
待務 wait / (perform) duty
待無 wait / not, none, cease to be
待謀 wait / plot, strategem
待矛 wait / halberd, lance, spear
待夢 wait / dream
待霧 wait / mist, fog
代武 replace, world, generation, fee / military, warrior
代務 replace, world, generation, fee / (perform) duty
代無 replace, world, generation, fee / not, none, cease to be
代謀 replace, world, generation, fee / plot, strategem
代矛 replace, world, generation, fee / halberd, lance, spear
代夢 replace, world, generation, fee / dream
代霧 replace, world, generation, fee / mist, fog
帯武 belt, obi, wear, zone / military, warrior
帯務 belt, obi, wear, zone / (perform) duty
帯無 belt, obi, wear, zone / not, none, cease to be
帯謀 belt, obi, wear, zone / plot, strategem
帯矛 belt, obi, wear, zone / halberd, lance, spear
帯夢 belt, obi, wear, zone / dream
帯霧 belt, obi, wear, zone / mist, fog
隊武 corps, unit / military, warrior
隊務 corps, unit / (perform) duty
隊無 corps, unit / not, none, cease to be
隊謀 corps, unit / plot, strategem
隊矛 corps, unit / halberd, lance, spear
隊夢 corps, unit / dream
隊霧 corps, unit / mist, fog
退武 retreat, withdraw / military, warrior
退務 retreat, withdraw / (perform) duty
退無 retreat, withdraw / not, none, cease to be
退謀 retreat, withdraw / plot, strategem
退矛 retreat, withdraw / halberd, lance, spear
退夢 retreat, withdraw / dream
退霧 retreat, withdraw / mist, fog
貸武 lend, loan / military, warrior
貸務 lend, loan / (perform) duty
貸無 lend, loan / not, none, cease to be
貸謀 lend, loan / plot, strategem
貸矛 lend, loan / halberd, lance, spear
貸夢 lend, loan / dream
貸霧 lend, loan / mist, fog
態武 appearance, intent / military, warrior
態務 appearance, intent / (perform) duty
態無 appearance, intent / not, none, cease to be
態謀 appearance, intent / plot, strategem
態矛 appearance, intent / halberd, lance, spear
態夢 appearance, intent / dream
態霧 appearance, intent / mist, fog
耐武 endure, bear / military, warrior
耐務 endure, bear / (perform) duty
耐無 endure, bear / not, none, cease to be
耐謀 endure, bear / plot, strategem
耐矛 endure, bear / halberd, lance, spear
耐夢 endure, bear / dream
耐霧 endure, bear / mist, fog
怠武 be lazy, neglect / military, warrior
怠務 be lazy, neglect / (perform) duty
怠無 be lazy, neglect / not, none, cease to be
怠謀 be lazy, neglect / plot, strategem
怠矛 be lazy, neglect / halberd, lance, spear
怠夢 be lazy, neglect / dream
怠霧 be lazy, neglect / mist, fog
胎武 womb / military, warrior
胎務 womb / (perform) duty
胎無 womb / not, none, cease to be
胎謀 womb / plot, strategem
胎矛 womb / halberd, lance, spear
胎夢 womb / dream
胎霧 womb / mist, fog
泰武 calm, serene, big, thai / military, warrior
泰務 calm, serene, big, thai / (perform) duty
泰無 calm, serene, big, thai / not, none, cease to be
泰謀 calm, serene, big, thai / plot, strategem
泰矛 calm, serene, big, thai / halberd, lance, spear
泰夢 calm, serene, big, thai / dream
泰霧 calm, serene, big, thai / mist, fog
袋武 bag, pouch / military, warrior
袋務 bag, pouch / (perform) duty
袋無 bag, pouch / not, none, cease to be
袋謀 bag, pouch / plot, strategem
袋矛 bag, pouch / halberd, lance, spear
袋夢 bag, pouch / dream
袋霧 bag, pouch / mist, fog
逮武 chase, seize / military, warrior
逮務 chase, seize / (perform) duty
逮無 chase, seize / not, none, cease to be
逮謀 chase, seize / plot, strategem
逮矛 chase, seize / halberd, lance, spear
逮夢 chase, seize / dream
逮霧 chase, seize / mist, fog
替武 exchange, swap / military, warrior
替務 exchange, swap / (perform) duty
替無 exchange, swap / not, none, cease to be
替謀 exchange, swap / plot, strategem
替矛 exchange, swap / halberd, lance, spear
替夢 exchange, swap / dream
替霧 exchange, swap / mist, fog
滞武 stop, stagnate / military, warrior
滞務 stop, stagnate / (perform) duty
滞無 stop, stagnate / not, none, cease to be
滞謀 stop, stagnate / plot, strategem
滞矛 stop, stagnate / halberd, lance, spear
滞夢 stop, stagnate / dream
滞霧 stop, stagnate / mist, fog

I'm sure we could find something meaningful in there. ^_^

Larry

Zowie

unread,
Aug 16, 2005, 11:31:27 AM8/16/05
to Dave Rolsky, perl6-l...@perl.org
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.

Dave Rolsky

unread,
Aug 16, 2005, 12:08:19 PM8/16/05
to perl6-l...@perl.org
On Tue, 16 Aug 2005, zowie wrote:

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

Well, if you want accuracy you need to get that info one way or another,
right? Although since most servers use NTP (or whatever MS uses), and
that ultimately goes back to UTC from atomic clocks, you can always get an
accurate local time (except _during_ leap a second when POSIX goes
insane).

Anyway, I don't think we should worry about this too much. There are a
couple of ways to use epochs. One is to use it for sorting/comparison,
like for file last mod times. In that case, the actual datetime the epoch
represents is irrelevant. If you need to do anything with the actual
datetime, I think it's best to turn it 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
encourage people to always use one of these, then hopefully most people
will never need to care what Perl6's epoch actually _means_. It's just a
magic number you pass to some function or library.

Autrijus Tang

unread,
Aug 16, 2005, 12:12:41 PM8/16/05
to perl6-l...@perl.org
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 UTC keeps screwing around with leap seconds, and civil time
> stays locked to UTC. I personally think we should add a bunch of leap
> seconds at the beginning of every year divisible by 100, and leave the
> rest of the years alone.

...This seems to be quite consistent with the rumoured US proposal to
abolish leap seconds by adding leap hours every 500 years or so:

http://www.post-gazette.com/pg/05210/545823.stm

Ending leap seconds would make the sun start rising later and later by the
clock -- a few seconds later each decade. To compensate, the U.S. has
proposed adding in a "leap hour" every 500 to 600 years, which also
accounts for the fact that the Earth's rotation is expected to slow down
even further. That would be no more disruptive than the annual switch to
daylight-saving time, said Ronald Beard of the Naval Research Laboratory,
who chairs the ITU's special committee on leap seconds and favors their
abolishment. "It's not like someone's going to be going to school at four
in the afternoon or something," he said.

Thanks,
/Autrijus/

Brano Tichý

unread,
Aug 16, 2005, 12:39:00 PM8/16/05
to perl6-l...@perl.org
<delurk>

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 unit when comparing
times. Only issues left are intervals; I vaguely remember something about
losing precision when subtracting two close floating-point numbers.)

I ask because I stumbled across uuu time
(http://www.unununium.org/articles/uuutime) when I was looking for
explanation of UTC/TAI/*J*D et al. It is counted from 2000-01-01 TAI in
microseconds and stored in signed 64 bit integer.


brano

</delurk>

Dave Rolsky

unread,
Aug 16, 2005, 12:26:54 PM8/16/05
to perl6-l...@perl.org
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.

Craig DeForest

unread,
Aug 16, 2005, 12:56:18 PM8/16/05
to Brano Tichý, perl6-l...@perl.org
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 likely to have implemented his/her own
library. Further, the trade between distance from the epoch and time
resolution goes in the correct direction -- e.g. nobody wants
microsecond precision when considering times 1,000,000 years in the
past. Finally, floating point encapsulates nicely the practical
nonexistence of simultaneity ( "$t1 == $t2" makes no sense without a
measure of the allowed slop; integer times force an implied slop
scale. )

Larry Wall

unread,
Aug 16, 2005, 1:28:47 PM8/16/05
to perl6-l...@perl.org
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...

Larry

Mark Reed

unread,
Aug 16, 2005, 1:18:40 PM8/16/05
to Brano Tich‡, perl6-l...@perl.org
On 2005-08-16 12:39, "Brano Tich‡" <ti...@dss.sk> 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 comparisons,
> but one can argue one should always specify the smallest unit when comparing
> times. Only issues left are intervals; I vaguely remember something about
> losing precision when subtracting two close floating-point numbers.)

Floating point has the advantage of great range without great storage
requirements; you can represent times far in the past or future, but the
further away from time 0 you go, the less resolution you have. Which is
usually perfect for real-life applications.

For example, given a 64-bit IEEE double-precision floating point
representation with 1-second units, you can represent time between points
about 10^308 seconds (3x10^300 years) before and after the epoch - which is
about 10^290 times the oldest estimates of the age of the universe. But at
those extremes, the time *between* representable points is a whopping
2x10^292 seconds (6x10^284 years).

At the other extreme, you have precision down to 1/10^308 of a second on
either side of the epoch itself.

Sam Vilain

unread,
Aug 16, 2005, 8:14:47 PM8/16/05
to Larry Wall, perl6-l...@perl.org
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?
> Because I'm a megalomaniac, silly dilly. Plus I like round numbers.
> Not to mention the fact that it makes it really easy to calculate days
> since 2000, give or take a squishy leapsecond or three.
> 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.

Why on earth would you want to encourage such a short sighted
programming practise? The earth wobbles like a spinning top. In fact
its speed increased after the two major Earthquakes in Antarctica and
Indonesia last December. Subtle adjustments are necessary to track
this; perhaps including the possibility that the Earth's rotational
speed might change by more than one second per day. Just why were the
Mayan, Babylonian and Aztec calendars 360 days long, anyway? Were days
20 minutes longer then? These are questions I've been wondering as an
old machine I have loses about this amount ... it would certainly
explain it if the machine was actually so old it used a Mayan timer
chip. (Sometimes the impossible has a coherency to it that the merely
improbable simply lacks...)

How about killing the argument by saying the epoch is only guaranteed by
the language to be relative to the same value within the lifetime of a
script, relative to 0.0 TAI in 1958 or whenever it was. Then Perl 6
implementations are free to pick their own epoch, and possibly also
annotate the time via traits/properties as not being confirmed to be NTP
synced, etc. Date modules (which, really, people should be using) then
have something sensible to work with and can easily provide the
alternate times. Environments that really can't guarantee an absolute
epoch can simply return unanchored times and let the modules throw
exceptions when you try to convert them to real times or times with
impossible levels of accuracy.

Sam.

Dave Rolsky

unread,
Aug 17, 2005, 2:28:32 AM8/17/05
to perl6-l...@perl.org
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_ care about syncing to
midnight can still have them, but the rest of the world would be just fine
with a leap hour every couple hundred years.

> synced, etc. Date modules (which, really, people should be using) then
> have something sensible to work with and can easily provide the
> alternate times. Environments that really can't guarantee an absolute
> epoch can simply return unanchored times and let the modules throw
> exceptions when you try to convert them to real times or times with
> impossible levels of accuracy.

Great, so now code that works in one environment throws a "cannot find an
up-to-date leap seconds table" exception in another? Eek!

Sam Vilain

unread,
Aug 18, 2005, 1:33:07 AM8/18/05
to Dave Rolsky, perl6-l...@perl.org
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 few people who _really_ care about syncing to
> midnight can still have them, but the rest of the world would be just fine
> with a leap hour every couple hundred years.

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.

What else do you want the time of day to represent? You would prefer it
something completely arbitrary, just to make it easier to program with?

That we don't just use a straight solar clock is probably down to the
fact that it was technically infeasible to have one without a sundial,
which obviously doesn't work at night or in England.

> > alternate times. Environments that really can't guarantee an absolute
> > epoch can simply return unanchored times and let the modules throw
> > exceptions when you try to convert them to real times or times with
> > impossible levels of accuracy.
> Great, so now code that works in one environment throws a "cannot find an
> up-to-date leap seconds table" exception in another? Eek!

Well, only if you try to do something silly like ask for the number of
seconds between two points of time in different days a long time in the
future, where those times were composed from Gregorian components. If
you were to ask for the number of minutes, or not cross the boundary of
when leap seconds are allowed, then it would still be OK.

I would expect a similar exception if I tried to calculate the number of
hours between two dates in an unknown timezone.

Of course feel free to consider this all worthless heckling, given the
lack of time I've been putting towards an implementation of all this ;).

Sam.

Braňo Tichý

unread,
Aug 18, 2005, 3:30:03 AM8/18/05
to Sam Vilain, perl6-l...@perl.org
> 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.
>

Does the Dairy Farmer need time with seconds precision?
Would he know his longitude and how to make correction to the time?
(If he is a person, wouldn't it be easier for him just to buy GPS?)

> Of course feel free to consider this all worthless heckling, given the
> lack of time I've been putting towards an implementation of all this ;).
>
> Sam.
>

Same here.

Maybe this lengthy discussion isn't really that useful. I think it's about
defaults, but Perl6 will have packages -- so everyone not content with the
default handling of time will be able to override it. Or maybe there could
be a pragma (`no leapseconds`?). Or maybe there could be a package on CP6AN
named Time::Leapseconds::Data.

Related question: is it possible to specify validity of a package? Something
along the lines "this package starts to be deprecated/imprecise/outdated
after 2007".

braňo tichý

Dan Kogai

unread,
Aug 18, 2005, 6:14:44 AM8/18/05
to Larry Wall, perl6-l...@perl.org
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 ?

> 滞夢 stop, stagnate / dream

Perl6 to kansai.pm :)

All sounds pretty perl6 to me.

Oh, be careful of this one.

> 台無 stand, platform / not, none, cease to be

Usually this one reads 'Dai-Nashi' (kun-yomi), meaning "to blow from
grounds up".

Dan the Man from a Place with Too Many Puns and Funs

Reply all
Reply to author
Forward
0 new messages