Precise time



  • Not a WTF really. More of a "why would they think it's useful?".

    In .NET, how do you add hours to a DateTime?

    DateTime.AddHours(double hours);
    Same for AddMinutes, AddMilliseconds, AddDays.

    Seriously - why invite anyone to step into rounding error trap?
    I'm wondering now, how many milliseconds you've got to add, to have a problem with number representation... Maybe I'll check it later - normal projects are waiting :)
     



  • You also have AddTicks that adds a number of 100-nanosecond ticks to the DateTime. And the datetime is actually measured as the number of ticks since 12:00 midnight, January 1st 0001 AD.

    So the double is probably useful when adding a huge number of hours to a date in the stone ages. Maybe its useful in astronomical software? Calculate the moons position in
    32311321.2323212 hours from now?



  • [quote user="runegri"]

    Calculate the moons position in 32311321.2323212 hours from now?

    [/quote]

    I'd rather get that in seconds / ticks, because DateTime just got pwned (or I did some mistake - please correct me, if I'm wrong):

    Int64 testStart = (20000000000001L);
    DateTime test = new DateTime(testStart*10000);
    Console.WriteLine("{0}\n{1}", DateTime.MinValue.AddMilliseconds(testStart).Ticks, test.Ticks);

    My result:
    200000000000009984
    200000000000010000

    Time paradox for anyone? :)



  • [quote user="runegri"]

    You also have AddTicks that adds a number of 100-nanosecond ticks to the DateTime. And the datetime is actually measured as the number of ticks since 12:00 midnight, January 1st 0001 AD.

    [/quote]

    Are you sure? I thought it was 1600 AD (which is possibly even more WTF - 0001 is at least a pretty even number (1 being the second integer, but indeed the first year...)). At least, the Win32 API uses that time (epoch=January 1st 1601) for files: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcekernl/html/_wcesdk_win32_filetime_str.asp

     

    And I can find no mention of how this time measure interprets the several changes in calendars we've went through since that time. And I'm quite sure that none of you really know how many years ago year 1 actually was (years, months, days, hours and seconds have all been fudged by arbitrary constants in the calendar shifts).



  • > "why would they think it's useful?".

    To add fractions of an hour, perhaps? Any integer can be expressed without error as a double, so no loss of precision there... and if you need exact you could add ticks.

    Note that you can also use Add (or the + operatior) to add a TimeSpan, and a TimeSpan can be created using an integer for the number of hours... or you can use the various multiples of Ticks that are exposed.

     



  • [quote user="raluth"]
    Any integer can be expressed without error as a double, so no loss of precision there...
    [/quote]

    Look at example above - it's not without loss... 

    [quote user="raluth"]

    Note that you can also use Add (or the + operatior) to add a TimeSpan, and a TimeSpan can be created using an integer for the number of hours... or you can use the various multiples of Ticks that are exposed.

    [/quote]

    Point. But it's the same for years. So adding 4.5 years - how many days are you adding... or is it converted to ticks... by date, or by number of days? Does half-a-year have additional 12 hours, or not in a leap year?

    It's less confusing if you add integers - less stuff to worry about. Basically what's the reason to use AddWhatever, if you're not sure, if result will be correct?



  • [quote user="raluth"]

    > "why would they think it's useful?".

    To add fractions of an hour, perhaps? Any integer can be expressed without error as a double, so no loss of precision there... and if you need exact you could add ticks.

    Note that you can also use Add (or the + operatior) to add a TimeSpan, and a TimeSpan can be created using an integer for the number of hours... or you can use the various multiples of Ticks that are exposed.

     

    [/quote]

    No, adding fractions of an hour is silly. It's to let you add enormous numbers. An int would limit you to 4G, and Int64... okay, I can't possibly think of any reason you might need to add more than 16 exa-hours, even if datetime could hold that. =p



  • They maybe just hired some experts for platform independent interfaces to designing the .NET APIs.




  • The Gregorian calendar works in cycles of 400 years. 1601 - 2000 makes the first nice "round numbered" cycle after the start of the Gregorian calendar in 1583 and allows another "round numbered" cycle to start in 2001.



  • [quote user="olsner"]

    Are you sure? I thought it was 1600 AD (which is possibly even more WTF - 0001 is at least a pretty even number (1 being the second integer, but indeed the first year...)). At least, the Win32 API uses that time (epoch=January 1st 1601) for files: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcekernl/html/_wcesdk_win32_filetime_str.asp

    [/quote]

     

    Yep. Quite sure. Unless MSDN lies. http://msdn2.microsoft.com/en-us/library/system.datetime.aspx

    According to the docs a DateTime can represent any date between January 1, 0001 AD and December 31, 9999 AD with a 0.1 microsecond precision, which is quite impressive really. Not that I see the usefulness of it, but its quite cool anyway!


Log in to reply