21–30 of 222 posts
35. Two timezones that differ, will differ by an integer number of hours.
37. Okay, quarter hours.
38. Okay, seconds, but it will be a consistent difference if we ignore DST.
About #7: doesn't a month always end in the same year it started?
One of my favorites, encountered in the wild: Your system will never need to handle a time before 1970.
You know who goes to the doctor a lot? Centegenarians.
35. There are years past 2079. SQL Server smalldatetime only goes up to June 6, 2079
Who believes these things? February is always 28 days long? Any 24-hour period will always begin and end in the same day (or week, or month)? A week always begins and ends in the same month?
Who believes these things? February is always 28 days long? Any 24-hour period will always begin and end in the same day (or week, or month)? A week always begins and ends in the same month?
He's talking about test code. So if those test cases are missing, but the programmer thinks the tests are thorough, then it looks like the programmer believes those things (or forgot that they weren't true).
assert(month(now()) == month(now() + 24.hours))
About #7: doesn't a month always end in the same year it started?
Can someone explain #1? I suspect it has to do with crossing time zones?
35. Two timezones that differ, will differ by an integer number of hours.
36. Two timezones that differ will differ by an integer number of half hours. 37. Okay, quarter hours. 38. Okay, seconds, but it will be a consistent difference if we ignore DST.
40. You can wait for the clock to reach exactly HH:MM:SS by sampling once a second.
If you really want to stress test time handling code, try to get it to accept Feburary 29, 1900 and Feburary 29, 2000. The first doesn't exist but the second does. But really, with regards to time use whatever library came with you programming language.