Update internal to avoid precision destruction

[psionic-k]

First things first regarding #25

I noticed while writing a test that #'ts-apply and `#'ts-update' were mutating the unix time even though it's unnecessary.

A proper fix started to rabbit hole a bit:

• If calling ts-apply with just a :unix time, there's no need to update the unix time again in ts-update. Every other slot could update if non-nil, but the unix time should not
• There is no error when calls are made with both unix or internal and any combination of day, month etc, but these calls are surely an improper usage

The kinds of tests I was running and expecting to work:

(let* ((time (float-time))
                 (ts (ts-apply :unix time (ts-now))))
     `(,(ts-internal ts)
       ,(time-convert time t)))
;;  ((7133786877722624 . 4194304)
;;   (7133786879364915 . 4194304))

ts-update is not taking the easy path...

Here's another test

(let* ((time (time-convert (current-time) t))
                 (ts (ts-apply :internal time (ts-now))))
     `(,(ts-unix ts)
       ,(float-time time)))
     
(1700827572.0 1700827572.2982888)

Ah, so both times are actually truncating to seconds unnecessarily. I can expand the scope of the PR if you think it's likely to pay off.

[alphapapa]

Thanks.

[alphapapa]

If we're going to test this, we should probably ensure that each element is an integer, as intended. I'd probably use pcase.

[alphapapa]

Why use funcall instead of calling time-convert directly?

[psionic-k]

Unless I missed something decode-time always loses precision. Even if every slot is populated, they could destroy precision when used to update the unix and or internal time.

Minor aside, I couldn't find a way to use fset with (decoded-time-year (decode-time)), which would make it much more obvious when doing mutations on those time structures. Never mind. setf all good. 🤡

I don't quite understand the README selling point about string-to-number. What's wrong with decoded-time-year?

[alphapapa]

Unless I missed something decode-time always loses precision. Even if every slot is populated, they could destroy precision when used to update the unix and or internal time.

Ok, I'm taking your word on that for now.

I don't quite understand the README selling point about string-to-number. What's wrong with decoded-time-year?

This package predates that and similar functions. If those functions had existed, I might not have written this library, or it might have been written as a thin wrapper around them.

Nevertheless, I suspect this package may still have a performance advantage when only one or a few slots are needed, because it avoids decoding all slots. But I don't have time to re-benchmark the whole package against the latest date/time functions in current Emacs now.