Pondering 2038

Posted Aug 20, 2013 0:26 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
In reply to: Pondering 2038 by ras
Parent article: Pondering 2038

Please, no base-two fractions. We will have tons of WONDERFUL problems trying to convert them to whole seconds and milliseconds.

to post comments

Pondering 2038

Posted Aug 20, 2013 0:38 UTC (Tue) by ras (subscriber, #33059) [Link] (3 responses)

> We will have tons of WONDERFUL problems trying to convert them to whole seconds and milliseconds.

I'm courious. What wonderful problems? I've been doing for ages - from back when the 8086's div instruction cost 10's of cycles. It was done that way for a couple of reasons. Firstly (and oddly enough), binary computers are rather good at handling binary factions. For them it's faster and simpler than base 10. And secondly, the hardware timers usually counted in binary fractions, so inevitably someone, somewhere has to do it.

Pondering 2038

Posted Aug 20, 2013 11:22 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

In one of my previous lives I was developing a staffing and accounting package. We had the following problem:

An employee is paid (say) $20 per hour and has worked 1 hour and 7 minutes. How much do we pay them for these 7 minutes? Well, the answer is ($20 * 7/60) = $2.33, right?

Except that then an accounting system tried to get time back by dividing $2.33 by 20 and getting 6.99(9) minutes which are rounded to 6 minutes. And we get a discrepancy in the reports. Not nice at all.

Here we'll have the same problem - it's not possible to express time periods like 100 msec in binary-based fractions. It might not be critical, but if you have applications where you do a lot of statistics it might get in the way (http://www.ima.umn.edu/~arnold/disasters/patriot.html - the famous example of this).

Pondering 2038

Posted Aug 20, 2013 13:12 UTC (Tue) by ras (subscriber, #33059) [Link] (1 responses)

> it's not possible to express time periods like 100 msec in binary-based fractions

No it's not. But then again no one I know of stores or manipulates times in a raw struct timeval format either, so I doubt it will be a problem.

I always thought timeval's being a prick to work with was a nit. But since they force everyone to convert times to a more suitable format, perhaps that's a blessing in disguise. And as I mentioned before, binary fractions do have one advantage over other bases: they are faster to convert to a different unit.

BTW, did you notice the patriot missile's OS reported the time in 100ms units. It's a nice power of 10 - just what you are asking for. It didn't solve the problem.

Pondering 2038

Posted Aug 20, 2013 13:25 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Timeval is used for calendar time, so it makes total sense to use real calendar units. It's not an especially good for calendar values, but the intent is clear.

Using binary fractions makes little bit more sense for CLOCK_MONOTONIC - it's mostly used for relative periods anyway. But then we'll have those rare cases when we need to sync CLOCK_MONOTONIC with the real clock (i.e. 'how much I'm going to wait till the next 100ms period?') and we're back to square one.

For better or worse, we are used to milliseconds and not binary-based second fractions (mibiseconds?). So it makes sense to keep it that way.

Would have been nice to also have decimal hours...

> BTW, did you notice the patriot missile's OS reported the time in 100ms units. It's a nice power of 10 - just what you are asking for. It didn't solve the problem.
It's still the same problem, just from the other side.