Pondering 2038

Posted Aug 20, 2013 13:12 UTC (Tue) by ras (subscriber, #33059)
In reply to: Pondering 2038 by Cyberax
Parent article: Pondering 2038

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