Jared Rhine wrote:
> Gordon Henriksen wrote:
>
> > gmclock(out Nx)
> > UTC clock in seconds since 0000 hrs Jan 1, 2000,
> > ignoring leap seconds.
> >
> > tolocal out Nx, out Iy, in Nz
> > x is set to z converted to the local time zone. y <- 1
> > if Daylight Savings Time was in effect at z; y <- 0
> > otherwise.
> >
> > splittime Px, Nx
> > Splits date up like Perl 5 gmtime. (But without
> > annoying y -= 1900 and m -= 1?)
> >
> > add_months(out Nx, in Ny, in Nz)
> > Sets x to y + z months.
>
> This proposal was perhaps taken offline by the core team, but to avoid
> a Warnock, I'll pipe up and say I like this proposal as a core
> instruction set.
Thanks for the anti-Warnock.
> It'd be nice if the first item, "gmclock" wasn't defined in terms of
> "UTC". Regardless of the future fate of UTC leap seconds, any
> UTC-based clock would need to account for leap seconds going back,
> right? So it seems that GMT should be preferred in the core, with any
> UTC calculations being performed at the language or module level.
>
> So, "gmclock" seems the right opcode (not "utcclock"), making the
> definition "GMT clock in seconds since 0000 hrs Jan 1, 2000".
Fair enough. I wasn't trying to load terms for once. In point of fact,
this set of opcodes is very much agnostic to whether or not leap
seconds are used.
The reason that add_months belongs as an opcode is because there's been
no decision made re leap seconds, and in fact some anti-decisions have
been proposed. Without some way to manipulate dates in accordance with
the actual rules that get used (which might be platform dependent at
this point), a portable program can't be written. Were this decision
made solidly, then all of the ops except gmclock and possibly tolocal
would be better written as library code.
Were leap seconds to fall in the middle of a month, then we would need
to have an add_days op. Since that's not the case, the assumption that
a day is 86400 seconds long is safe so long as you avoid adding enough
days to cross a year boundary. Meanwhile, add_months encapsulates the
leap-second worries AND lets IMC code conveniently manipulate dates
without days-per-month tables and is-it-a-leap-year algorithms (which
are required to convert add_months to add_days).
> Daylight savings time calculation seems appropriate to stay in the
> core, but perhaps additional opcodes are need to set the clock's
> understanding of the time zone used for DST calculations?
Indeed; "the local time zone" is pretty narrow-minded and backwards-
thinking. The problem is balancing weight with efficiency, and time
zone databases are pretty heavy critters, which make me think "get
thee OUT of the core!"...
> > # years
> > Nz = Py[5]
> > Nz = Nz - 2000 # epoch based at year 2000
> > Nz = Nz * 12 # = months per year
>
> <inappropriate sarcasm>I look forward to the exciting advancement of
> changing from subtracting 1900 from all my dates to subtracting 2000
> or dealing with negative numbers; that'll change everything and really
> advance the state of the art.</sarcasm>
What you're complaining about is the elements of Perl's gmtime/localtime
arrays. Actually, I suggested removing that quirk from splittime:
> > splittime Px, Nx
> > Splits date up like Perl 5 gmtime. (But without
> > annoying y -= 1900 and m -= 1?) ^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The Nz - 2000 is conversion *to* the epoch, not reinterpreting the value
in the array.
Unless you think storing dates and times as the number of seconds since
Jan 1 0000 is a good idea, perhaps. :)
I'd used Jan 1 2000 as an epoch since Larry suggested that's what he was
planning for Perl 6 to use.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
