27.0.60; Asymmetry between (days-to-time) and (time-to-days)

27.0.60; Asymmetry between (days-to-time) and (time-to-days)

[Kevin Liu]

The asymmetry between (days-to-time) and (time-to-days) is quite surprising:

(format-time-string "%Y" (days-to-time (time-to-days (current-time))))
"3989"

One could work around this by using (time-to-number-of-days) which uses
the epoch time like (days-to-time), but that itself is awkwardly
asymmetric as it returns a float, as well as the asymmetric naming.

It's probably unrealistic that any existing behavior be changed, but it
would at least be nice to have a builtin function that is the inverse of
(time-to-days).  Org-mode, for example, seems to use the Gregorian
convention of (time-to-days) throughout, and to convert a (org-today) to
a time requires this mess:

(format-time-string "%Y" (days-to-time (- (org-today) 719162)))
"2020"

Re: 27.0.60; Asymmetry between (days-to-time) and (time-to-days)

[Paul Eggert]

On 3/24/20 2:18 AM, Kevin Liu wrote:
> The asymmetry between (days-to-time) and (time-to-days) is quite surprising:
> 
> (format-time-string "%Y" (days-to-time (time-to-days (current-time))))
> "3989"

Even if time-to-days and days-to-time were inverses, this usage would be dubious 
since the conversion back and forth would discard the fractional date and that 
could cause format-time-string to do the wrong thing when the timestamp was near 
a year boundary in a non-UTC timezone.

> It's probably unrealistic that any existing behavior be changed, but it
> would at least be nice to have a builtin function that is the inverse of
> (time-to-days).

We could add an optional argument to days-to-time; if it's t then days-to-time 
could add 719162 to its argument before converting (or whatever the magic number 
happens to be; I didn't check this).