Vladamir has a use case where the deprecation gives him a wall of
deprecation messages, and because he needs to use both 2.066 and master,
he can't move his code over to fracSecs yet. So, I'm changing the
deprecation to "scheduled for deprecation" for one release. And because
of this case, I think that I'm going to change the general policy to
"scheduling for deprecation" for one release before actually deprecating
a symbol. The fact that deprecated just generates a message mostly
obviates the need for "scheduling for deprecation" like we used to do,
but with this change, it will give folks one release to avoid the wall
of deprecation messages if they happen to use the deprecated symbol a
lot (or just once in a frequently instantiated template as in Vladamir's
case). It probably won't do anything for anyone who doesn't read the
changelog, but it will help out the folks who do.
I also added a script at the bottom of std.datetime which can be used to
regenerate the conversions from the latest conversion file at
unicode.org so that it will be much easier to make such updates in the
future.
FracSec is overly verbose and based on the recent discussions with
regards to Duration.get and Duration.split, it should be given the boot.
The only non-deprecated place which uses it in Phobos is SysTime, so
this deprecates the functions that use it, and replaces it with ones
that expect a Duration of less than one second.
This means replacing a SysTime constructor and SysTime's fracSec
property. fracSecs is introduced to replace fracSec. It uses a Duration
or takes a template argument for the units and then uses an int
(essentially then creating an overload which is a shortcut for calling
Duration.total or creating a Duration, depending on whether its the
getter or the setter).
The RFC 822 / 5322 date-time format should be taken out and shot, but
unfortunately, it _is_ used in e-mail, HTTP, RTSP, etc. Most code which
deals with it is probably going to need to handle the rest of whatever
spec it's interacting with rather than just the date-time format, but
there are cases where this would be useful on its own (e.g. Martin
apparently needs something like this in the dmd installer), so I'm
adding a function to parse this format and return a SysTime to
std.datetime.
However, that's all I'm adding. I find it very hard to believe that
anyone who needs to produce this particular format doesn't need a lot of
other functionality specific to whatever spec they're dealing with, and
the function for generating the date-time format presumably will be
included with that (and I definitely don't want to encourage this
format's use anyway, since it's a horrible format). So, I'm just adding
a function for parsing the format, not generating it.
parseRFC822DateTime _should_ fully and correctly implement the format as
outlined in RFC 5322 (including the obsolete syntax from RFC 822 that no
one is supposed to be generating anymore and the comment folding
whitespace nonsense that should never have been legal anywhere but at
the end). And the tests are quite thorough, so it's unlikely that I
missed anything, but you never know.
