how about opcode formatting primitives? That is what I would argue
strftime and relatives are... generic low-level ways of turning strings
into dates into numbers (seconds) and vice-versa.

That they are part of a standard low-level library (libc) that is widely
available and can be described in terms of parrot primitives (strings, numbers),
and the fact that this low-level library is well known, tested and
supported on various platforms just seems to me to be a tremendous timesaver.

I agree that facilitating easy bytecode writing is really important - but
reimplementing a pretty standard wheel and having that pretty standard wheel
be slower than what is available doesn't seem to be useful to me. Taking
the standard wheel and augmenting it seems more useful IMO.

I tell you what - why don't base your decision on an empirical test.
I'll write a c program around strftime that does a given
set of formatting dates and times, as well as the reverse translation, and
we can benchmark that program versus the bytecode that parrot offers in a stdlib on
a list of tasks.

After some optimising iterations, we'll compare the results. And depending
on the performance difference, you can decide whether or not its worth the effort
to put these primitives in the core.

And the more I think about it, the more I think this concern is misplaced.
Putting it in an opcode will make it *harder* to do this type of thing, not easier.
In perl5 land, backwards - and forwards - compatibility is a big concern. There will
be a large tendency to stabilize any implementation that occurs here.

Ed