* highly-precise (nano-second or better) time has any intrinsic meaning at all (relativity)
Falsehoods Programmers believe about Time
201–210 of 222 posts
Re: Falsehoods Programmers believe about Time
#202Earlier quoted context omitted.
UTC time does not go backwards. Leap seconds are implemented as a minute with 61 seconds.
Ok, I oversimplified. UTC time does not go backwards, but the value returned by POSIX time(3) -- which is supposed to be the number of seconds since 1970-01-01 00:00:00 UTC -- does. (Assuming you have sub-second precision, of course; time_t isn't required to be an integer type, and there's other APIs which access the same UTC-seconds clock and provide microsecond or nanosecond precision.)
The value returned by POSIX time is commonly said to be "POSIX time" or "UNIX time". This names a time system other than UTC. In my experience, programmers don't seem to confuse these two systems.
I have seen good programmers be surprised by the fact that POSIX time goes backwards in the event of leap seconds, as I was when I learned it. I think it would have at least as much punch if you edited your "falsehood 2" to be about UNIX time instead of UTC. As a bonus, you would also be correct ;)
Re: Falsehoods Programmers believe about Time
#203* floats are ever a good idea for storing time. a system i use (no, not excel) has one of its time types defined as a double of days since their epoch. the problem is that it's universally represented in the interface as a timestamp to millisecond precision, and many different values may have the same string representation.
i just ran a quick test, and for a specific millisecond around now, about 13,000 distinct timestamps have the same string representation. if you use that string representation as a serialization of any one of those timestamps, it will always map back to a single float value, which will be only one of those 13,000, meaning the others aren't round-trippable.
the system implements a comparison tolerance for floating point numbers, but this helps only slightly, as only about 1100 of those 13,000 test as equal to the one you get if you enter it as a string.
the end result is that you can have data printing to the screen that you can't actually find in the system because its string representation doesn't match its internal one due to precision issues.
(the solution is not to use the type--they deprecated it in favor of one based on longs of nanos several years ago.)
Re: Falsehoods Programmers believe about Time
#204Earlier quoted context omitted.
...except that there were countries that weren't using the Gregorian calendar until well into the 20th Century , so you can't even reliably deal with dates as recent as the mid-1900s across borders under that assumption. But don't worry, they're just small countries. Like Russia. And China.
I suspect that even in China and Russia, most software will require that dates be entered as if the current Gregorian Calendar had always applied.
Imagine a historical database of Russian birthdays, copied from historical archives by data-entry clerks who had no idea when Russia switched from the Julian to the Gregorian calendar. (For extra fun, imagine that half of the clerks doing the data entry converted the dates before entering them, and half didn’t.)
Re: Falsehoods Programmers believe about Time
#20535. 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.
What has a non-integral number of seconds?
I just found out today about Calcutta time, which until 1948 was GMT+05:30:21, but I didn ’t realize it could be even worse than that.
Re: Falsehoods Programmers believe about Time
#206How about some calendaring issues I'm sure any Israeli is familiar with: 1. Weeks start on Monday. 2. Days begin in the morning. 3. Re: 2, holidays span an integer number of whole days. Explanations: 1: In Israel, the week starts on Sunday. Most programs have support for changing the "start of week day". Most programs. 2-3: In the Jewish calendar, the day starts when the moon comes out. This means that holidays that…
> In the Jewish calendar, the day starts when the moon comes out. say what? afaik (speaking as a jew here), it's when the sun goes down. (moonrise, averaged over all time, happens at any point in the 24-hour cycle.) possibly you're thinking of when (jewish calendar) months start?
Well technically it's when 3 stars come out.
Actually I just checked to make sure, it turns out the 3 stars thing is based on a definition by Maimonides: http://en.wikipedia.org/wiki/Jewish_calendar#Measurement_of_....
Re: Falsehoods Programmers believe about Time
#207From the headline, my first thought was that this was going to be about estimating development time/effort on a project.
Re: Falsehoods Programmers believe about Time
#208Earlier quoted context omitted.
The way you're thinking about it, yes -- but the passage of a month may take you from December the [mumbleth] to January the [mumbleth], which are in different years. For some strange reason, code in the wild doesn't always account for that, so the due date for an item may well be eleven months before the request was entered.
One I caught recently: The difference between the current time and one week from the current time is not always 7 * 86400 seconds. By noticing an automated test that failed 2 weeks out of the year.
I think every test suite has tests that only fail right around the start and end of daylight savings time.
Re: Falsehoods Programmers believe about Time
#209Earlier quoted context omitted.
Ok, I oversimplified. UTC time does not go backwards, but the value returned by POSIX time(3) -- which is supposed to be the number of seconds since 1970-01-01 00:00:00 UTC -- does. (Assuming you have sub-second precision, of course; time_t isn't required to be an integer type, and there's other APIs which access the same UTC-seconds clock and provide microsecond or nanosecond precision.)
The value returned by POSIX time is commonly said to be "POSIX time" or "UNIX time". This names a time system other than UTC. In my experience, programmers don't seem to confuse these two systems. I have seen good programmers be surprised by the fact that POSIX time goes backwards in the event of leap seconds, as I was when I learned it. I think it would have at least as much punch if you edited your "falsehood 2" to…
Yeah, I should have just said UNIX time.
Re: Falsehoods Programmers believe about Time
#210How about some calendaring issues I'm sure any Israeli is familiar with: 1. Weeks start on Monday. 2. Days begin in the morning. 3. Re: 2, holidays span an integer number of whole days. Explanations: 1: In Israel, the week starts on Sunday. Most programs have support for changing the "start of week day". Most programs. 2-3: In the Jewish calendar, the day starts when the moon comes out. This means that holidays that…
Actually, in Jewish tradition, children are taught that the day begins at sunset. The justification comes from Genesis... "And God called the light Day, and the darkness he called Night. And the evening and the morning were the first day."
The Moon is not mentioned.