• 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)

    I give you Tom Scott - Timezones . It contains some real goodies.

  • (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.

  • (nodebb) in reply to Jaime

    Even during leap years, it's reasonable to say the 1:00am March 1st is 26 hours after 11:00pm February 28th.

    I think you meant to say "Only during leap years,". In any non-leap Julian(1) or Gregorian(1) calendar year, that difference is only two hours.

    (1) The change from Julian to Gregorian only changes which years are leap years, not the behaviour of the boundary.

  • (nodebb)

    "Time, time, time... See what's become of me!"

    Who knew that Paul Simon was a programmer?

  • Ishura (unregistered)

    For what it's worth, the current version of the code says 366. The particular repo that's been linked from the article is the "reference source" of the old previously-closed-source .Net Framework.

  • Michael R (unregistered) in reply to The Beast in Black

    Time why you punish me Like a wave bashing into the shore You wash away my dreams Time why you walk away Like a friend with somewhere to go You left me crying

    Who knew Hootie & the Blowfish were programmers too?

  • NegativeDay (unregistered) in reply to Officer Johnny Holzkopf

    Only if you are doing naughty homemade date math. I would assume that DateTime class has some kind of AddTimeSpan method that correctly handles it, returning the date and time after the given period elapsed. There is no reason to expect this to be handled on the level of the TimeSpan class. It logic related to the date, not to the time span, the time span is invariant

  • securityinteractive (unregistered) in reply to COBOL Dilettante

    I thought Noda Time fixed all this chicanery

  • (nodebb) in reply to Darren

    @Darren Ref

    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.

    IMO ... Not really. Had we done that we'd have had all the idiosyncrasies of Swatch time and all the idiosyncrasies of conventional time, and all the tomfoolery of interconverting for display or import / export purposes.

    You think date libraries are trouble now, just you wait until we have 3x (at least) the opportunity for dumbf***ery.

  • Officer Johnny Holzkopf (unregistered)

    Apparently, Mantrid also was a programmer: "Time... has not been kind to me..."

  • Blue (unregistered)

    I had to look to see it for myself, but the comment says "365 or 366 days". It was fixed 4 years ago in November 2022

  • Clive Page (unregistered)

    It's worse than that because of leap seconds. A day may be 86401 or 86399 seconds long just occasionally.

  • (nodebb)

    02/30/1712 , Sweden.

    Addendum 2026-07-31 22:54: Feb 30th 1712, Sweden

  • (nodebb)

    A decade can have between 1 and 3 leapyears,

    Took me a minute to think of a 10 year interval with only one leap year in it. The town years starting at the beginning of 1897 would be one such interval.

    Addendum 2026-08-05 09:43: s/town/ten/

  • Craig (unregistered) in reply to Steve_The_Cynic

    TRWTF is (most of) Indiana switching from EST to EDT in the summer leading to 9:30 pm sunsets.

Leave a comment on “Negative Days”

Log In or post as a guest

Replying to comment #702685:

Log Out

« Return to Article