I don't agree with this statement at all. Hasn't the System.TimeSpan existed for a much longer time than Sql.Time? So how could it possibly be an offer to support Sql.Time when that didn't exist? I can say for sure that I have used TimeSpan in the past for tracking things like the amount of time it'll take to travel from point A to point B. That's something which is very different than Sql.Time, so should it not be supported?
It seems like the goal should be able to take a value, save it, load it back and still have the same value, regardless of what the common usage is. There are plenty of applications that use it correctly, but in a different way. On Wed, Mar 25, 2009 at 12:43 PM, Dario Quintana < [email protected]> wrote: > System.TimeSpan is what .Net offers to match a Sql.Time. > > There is no real discussion about the 1657 since nobody showed interest. > The reason of these changes are the types introduces on .Net 2 Sp1 > > On Wed, Mar 25, 2009 at 1:22 PM, Oskar Berggren > <[email protected]>wrote: > >> To me it seems quite weird that a CLR TimeSpan by default be stored as a >> sql TIME, since they are conceptually different things. And with the wildly >> different ranges there is as seen a practical difference too. >> >> I can find no real discussion on this change in NH-1657 and in the mail >> archives, though it was mentiond on Feb 5th. What is the reasoning behind >> this move? Has anyone actually requested this change? >> >> /Oskar >> > > > -- > Dario Quintana > http://darioquintana.com.ar > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
