On 2011-05-08 21:29, Adam D. Ruppe wrote: > Jonathan M Davis wrote: > > I would point out though that'll be a while before std.date and its > > related functions actually go away, so any code which needs to be > > converted to std.datetime definitely has time to be reworked > > however is appropriate. > > Yeah, but I figure it's better to do it sooner than later. The more > I wait, the more data I've got to deal with converting and the more > users I risk angering too.
Oh, I totally agree that it's generally better to switch sooner rather than later, but you do have time to figure out what the best solution is in your situation rather then being in a situation where all of your code is about to break because std.date is eminently disappearing. Also, any insights into where std.datetime might have problems integrating with formats that you might have to keep your time in (other than d_time) would be useful. So, if you see areas where std.datetime is just plain lacking (as opposed to just being different), feel free to point them out. It's a very different type of solution than std.date was though, so it could take some getting used to. std.date was essentially the same solution as C except that it made d_time hold milliseconds whereas time_t holds seconds. std.datetime, on the other hand, is very much an object-oriented solution. - Jonathan M Davis
