Gordon>     gmclock(out Nx)
Gordon>         UTC clock in seconds since 0000 hrs Jan 1, 2000,
Gordon>         ignoring leap seconds.

Gordon>     tolocal out Nx, out Iy, in Nz
Gordon>         x is set to z converted to the local time zone. y <- 1
Gordon>         if Daylight Savings Time was in effect at z; y <- 0
Gordon>         otherwise.

Gordon>     splittime Px, Nx
Gordon>         Splits date up like Perl 5 gmtime. (But without
Gordon>         annoying y -= 1900 and m -= 1?)

Gordon>     add_months(out Nx, in Ny, in Nz)
Gordon>         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.

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

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?

Gordon>    # years
Gordon>    Nz = Py[5]
Gordon>    Nz = Nz - 2000    # epoch based at year 2000
Gordon>    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>

Of course, as Gordon suggests, what I'll actually be doing is relying
on some Perl 6 module to give me a nice (non-negative date) object
interface.  The Parrot instruction should probably be optimized for
speed.  Formatting can always be kludged together at the language
level, but a module will need solid support from Parrot for good
duration calculations.  Gordon's proposal is tuned for duration
calculations, which is ideal.

It'd be great, if possible, to get a statement here from the DateTime
group sanctioning one or another particular Parrot clock interfaces as
"efficient, complete, and preferred".  I haven't poked over to see
if they are chatting about this Parrot issue.

-- ja...@wordzoo.com

"A black hole is where God is dividing by zero."
        -- attributed to Roger Smith