These have been deprecated for a while, but there was some balking
(primarily from Andrei IIRC) at actually removing them when they were
slated for removal, so they were instead made undocumented and slated
for removal after yet another 6 months or so. So, now that that time has
passed, here's another attempt to actually remove them.
I don't think that it makes any sense for core.time.TickDuration.to to
be a property, since it's a conversion function, not an abstraction for
a variable. However, it _does_ make sense for the example to use one of
TickDuration's property functions instead (it makes the code cleaner
too). So, I've done that. And if the property debate results in
non-property functions being allowed to be called without parens (as
currently seems likely), then anyone wanting to use the to function
without the extra parens can do so then.
hasOverloadedOpAssignWithDuration!T returns true even if T is not a mutable type (e.g. for const Date). But, until now, the type of T.init had been accidentally unqualified by bug 9046.
Several deprecated items were listed for removal in August, but it's
looking likely that 2.060 will come out in August, and I'd prefer not to
have them removed for 2.060 given how many items are already in the
changelog, and they're already deprecated, so it'll only affect people
compiling with -d either way. So, I'm changing the ddoc comments to say
September instead of August. They'll be removed in 2.061.
I may or may not re-add it later, but it's probably going to be broken
for a while, depending on how long it takes the various auto tester
boxes to be updated, since a new leap second was applied on 2012-06-30
right before midnight of 2012-07-01. The total is now 25, but some
machines will think that it's 24 for a while.
Both FILETIME and SysTime store time as the number of elapsed hnsecs
since a certain (different) epoch. Therefore, the optimal way to convert
between the two would be simply adding/subtracting the epoch difference.
This is not what std.datetime used to do - instead, FILETIME values
were converted to SYSTEMTIME (a structure with year/month/day/etc.
fields), and then created the SysTime result from that (and vice-versa),
which was very inefficient.
The "add epoch difference" method was already used in SysTime.currStdTime.
It has been refactored out and used in FILETIME conversion functions.
It looks like testing America/Santiago just isn't going to work, since
it's failing on FreeBSD. Bleh. Getting a timezone to test in South
America which actually has DST and works on all OSes is a pain (and
seemingly impossible at the moment). All of the other Chile tests were
disabled anyway.
Chile is screwing with its DST again, and I made the mistake
of leaving one of the tests using a 2012 date instead of a 2011
date (since 2011 has already happened whereas 2012 is still subject
to change).
Having the January deprecations and February deprecations in the same
month seems a bit much to me, since we managed to have both of those
months have quite a few, whereas the next few months have very few if
any. And we're close to release too, so I'd prefer to avoid causing
issues by deprecating them now.
