> Leave parsing and formatting entirely to libraries. Absolutely no need
> for that in the instruction set.
well, I have a bit of a problem with that... As it was pointed out
before, people have gone hogwild with the parsing and formatting
routines, and its a bloodbath of modules on CPAN with different
methods for time parsing.
Which is a pity, because an augmented strftime and its reverse would
handle most if not all of the parsing needs, ie:
strftime( out Sx, in Sy, in Nz )
where
Sx is an output date string
Sy is a format described by strftime
(ex: %y = 2 digit year %Y = 4 digit year,etc)
Nz is the number of seconds past a certain epoch (provided by
gmclock,
time)
r_strftime( out Nx, in Sy, in Sz )
where
Nx is the number of seconds past a certain epoch
Sy is a format for a given date (provided by strftime)
Sz is the date to be converted to in seconds
Perhaps there could be an extra argument for locales - and maybe the
op could be split in two (ie: for (r_)gm_fmtime, (r_)local_fmtime),
but for me, in processing time values most of the time you know the
format for dates - as long as they are machine generated. If they are not,
you can always fall back to the very slow Date::Parse and cousins, or
maybe string these ops along in a chain of '||' to query for multiple
formats.
But how many times are you going to need to parse formats
like '3 weeks from next Wednesday?'.
Whether or not this is a low-level module or an op is debatable, but
standardizing on one type of formatting dates at the lowest possible
level would make perl6 much much cleaner. And right now, things are
way too slow - any low level module doing this would IMO need to do it
in C anyways to get the fastest possible speed, which seems to argue
for them being ops.
Ed
