- Feature Articles
- CodeSOD
-
Error'd
- Most Recent Articles
- The Song that Never Ends?
- Princess Pricing
- Einfach so
- Kaids Hen 2025
- Fi fa foe
- Microbits
- No Rush
- Bridge for Sale
-
Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
You had me at Silverlight . . .
Admin
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.
Edit Admin
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.
Admin
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"...
Edit Admin
Except in places where we don't. Example: Most of Arizona, except in the Navajo Nation. All of Hawaii.