Re: encode-time vs decode-time

[Lars Ingebrigtsen]

Paul Eggert <address@hidden> writes:

> OK, after some cogitation I installed something along those lines into
> master. I called the new function 'time-convert' by analogy with the
> existing functions time-add etc. So now, as you suggested, encode-time
> has reverted to its old role of converting from decoded timestamps to
> Lisp timestamps and its API is now simpler.

Great!  Thanks for doing this and adding the sub-second time to the
decoded time structure -- I'll be implementing the remaining bits of the
ISO 8601 standard in `iso8601-parse' (the ones that deal with fractional
seconds) so that we'll have a completely compliant parser.

> I didn't follow Stefan's suggestion of adding another function that
> acts like current-time except it returns the (TICKS . HZ) format,
> because current-time is already planned do exactly that after the next
> release (when we will default CURRENT_TIME_LIST to false) and it'll be
> simpler if we have one function rather than two that do the same
> thing.

However, I think this sounds overly ambitious.  I think it's likely that
there's tons of out-of-tree code that assumes that `current-time' always
returns a list of time values, because it's been that way since
basically forever.  It's been extended, but the first two elements have
always been a representation of seconds.

This is why I thought it would be good to introduce a new function, say
`get-current-time', that could have our new signature.  We'd then
deprecate `current-time' (but probably never actually remove it since
there's so much code out there in the wild that uses it) and rewrite all
calls in-tree to use this new function.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no