Well, my main problem with representing time as a pair, is that a point in time isn't uniquely defined (e.g. should it be 3s + 5e-11ps, or 2s + 5e-11ps), and that, in most suggested formats, they overlap (e.g. 3s or 2s + 1e12 ps). So you need to normalize -- possibly after each operation. Are you sure this is more efficient than using bignums?
Further, I'm not sure Haskell has a standard 64 bit Int. I'm fairly sure it's in GHC, and probably in the other compilers, but it'd be nice if it were in the standard. On the other hand, Integer can be implemented any way that's efficient on each architecture.
Haskell does have a standard 64 bit Int, known as Int64. (standard in the sense that the FFI addendum defines it, which is almost but not quite as standard as Haskell 98). If there are performance concerns, then we should measure both the version with an Int64 pair and the version with Integer. My guess is that there won't be enough of a difference for it to matter.
I find it hard to lose sleep over missing leap-seconds and dates beyond
Leap seconds are a completely orthogonal issue. From the discussion here, it seems plain that UTC is a kluge, and TAI is the way to go. In any case, we already agree to counting seconds, the question is how to count them :-)
UTC is only a kludge for the fact that the Earth wobbles a bit on its trajectory through space - I think that's a reasonable kludge :-) POSIX "seconds since the epoch" is a *real* kludge. Let's not get the two confused. Cheers, Simon