• Bogolese (unregistered)

    You had me at Silverlight . . .

  • Rob (unregistered)

    So there's no Years() or Months() because of different-length months and leap years, but there is Days() even though there's such a thing as daylight savings time. Where we have one day each year that is only 23 hours long, and one day that's 25 hours long. Guess the code doesn't take that into account.

    But they are not the only one. Java's Duration class also always divides seconds by 86400, ignoring DST.

  • (nodebb) in reply to Rob

    It doesn't really matter, because it represent a duration, independently from any specific calendar date or geographic location. As soon as you take the calendar and geography out of the picture, DST is meaningless.

  • Officer Johnny Holzkopf (unregistered) in reply to tom103

    It becomes "meaningful" (or confusing, to be precise) as soon as you introduce displaying times and duration at the presentation level, such as "start time: 1:30; end time: 4:30; duration: 5 hours" or "start time: 2:15; end time: 6:45; duration: 3 hours 30 minutes". Becomes even more interesting when slapping a price tag on "time consumed" and you take the wrong metric (clock-time difference, manually calculated, instead of actual duration). It can get even worse when you do "in and out with stringly-typed dates and crazy date + time arithmetic"...

  • (nodebb) in reply to Rob

    Where we have one day each year that is only 23 hours long, and one day that's 25 hours long

    Except in places where we don't. Example: Most of Arizona, except in the Navajo Nation. All of Hawaii.

  • Michael R (unregistered)
    Comment held for moderation.
  • (nodebb)

    Time is TRWTF, especially because no one knows its true nature or even what it should be - GR says it's relative, while quantum physics and the Schroedinger equation assume absolute time. And what is it really? Is it a base feature of reality, or is it just an emergent phenomenon arising out of the second law of thermodynamics?

  • (nodebb) in reply to Steve_The_Cynic

    If you travel on route 264 in arizona your clock can change time 6 times in 100 miles. but only in the summer.

  • Wyatt (unregistered)

    No, the real WTF is that the comment is wrong. Timespan is represented internally as the number of ticks, not the number of milliseconds. A tick is 1/10000 of a millisecond as represented by the TimeSpan.TicksPerMillisecond const.

  • Wyatt (unregistered)

    No, the real WTF is that the comment is wrong. Timespan is represented internally as the number of ticks, not the number of milliseconds. A tick is 1/10000 of a millisecond as represented by the TimeSpan.TicksPerMillisecond const.

  • COBOL Dilettante (unregistered)

    Let's make a date-handling library, but not support any of the things that make date-handling hard...

  • 516052 (unregistered) in reply to COBOL Dilettante

    Well to be fair, date handing is hard. ;)

  • Argle (unregistered) in reply to The Beast in Black

    That truly has the ring of a weekend in a college dorm involving a lot of weed.

  • Troy Roberts (unregistered) in reply to Rob

    DST does not change the number of hours is a day. It only renames them hours. 2AM Standard Time is not the same as 2AM Daylight Saving Time.

  • Randal L. Schwartz (github) in reply to Troy Roberts

    DST does not change the number of hours is a day. It only renames them hours.

    Welcome to date arithmetic. Yes indeed, DST makes one day a year to be 23 hours, and another to be 25 hours. Guaranteed. Compute the "noon-to-noon" difference between any pair of days, and you'll see that at the borders of DST, it does weird things.

  • (nodebb)

    The real WTF is thinking there's 364 days in a year.

  • Hmmmm (unregistered)

    And is anyone programming ahead for a multi-planetary civilization??

  • Darren (unregistered)

    We should have taken Swatch up on the opportunity to use their decimal-based Internet Time (aka .beat time) for all things online. Would have solved a lot of problems.

  • (nodebb) in reply to COBOL Dilettante

    Let's make a date-handling library, but not support any of the things that make date-handling hard...

    Not really. This is just a TimeSpan, which represents a duration. Even during leap years, it's reasonable to say the 1:00am March 1st is 26 hours after 11:00pm February 28th. There's no need to qualify the 26 hours as "leap hours" or some other such nonsense. Same with DST - sometimes 4am is three hours after 2am. Three hours is still three hours. The use would be (point-in-time-which-requires-crazy-calendar-metadata) + (timespan) = (point-in-time-which-requires-crazy-calendar-metadata). The timespan is just there so that the code doesn't have to extract raw seconds, minutes, or whatever, like we all did before we had rich libraries. With this, timespans have a clear data type and they don't get misapplied in invalid contexts.

Leave a comment on “Negative Days”

Log In or post as a guest

Replying to comment #702633:

Log Out

« Return to Article