Question about parse-time-string and date-to-time

Question about parse-time-string and date-to-time

[Eric Abrahamsen]

A conundrum:

parse-time-string accepts a string representing a date, and parses it
into a list of time elements, with nil for the unknowns.

date-to-time calls parse-time-string and passes the result straight to
encode-time, to produce a time value.

encode-time accepts series of time elements, and raises an error if any
of them are nil.

I might be missing something, but I don't see how date-to-time could
ever work. Wouldn't it always have to replace the nils with zeros before
passing the result to encode time?

Eric

Re: Question about parse-time-string and date-to-time

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> A conundrum:
>
> parse-time-string accepts a string representing a date, and parses it
> into a list of time elements, with nil for the unknowns.
>
> date-to-time calls parse-time-string and passes the result straight to
> encode-time, to produce a time value.
>
> encode-time accepts series of time elements, and raises an error if any
> of them are nil.
>
> I might be missing something, but I don't see how date-to-time could
> ever work. Wouldn't it always have to replace the nils with zeros before
> passing the result to encode time?

Or maybe time elements with nils for any of day/month/year are simply
considered invalid? 

Re: Question about parse-time-string and date-to-time

[John Mastro]

Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
> A conundrum:
>
> parse-time-string accepts a string representing a date, and parses it
> into a list of time elements, with nil for the unknowns.
>
> date-to-time calls parse-time-string and passes the result straight to
> encode-time, to produce a time value.
>
> encode-time accepts series of time elements, and raises an error if any
> of them are nil.
>
> I might be missing something, but I don't see how date-to-time could
> ever work. Wouldn't it always have to replace the nils with zeros before
> passing the result to encode time?

It looks like, if the first call to `encode-time' signals an error, it
re-tries using the result of calling `timezone-make-date-arpa-standard'
on the original DATE argument:

    (defun date-to-time (date)
      (condition-case err
          (apply 'encode-time (parse-time-string date))
        (error
         ;; ...
         (apply 'encode-time
                (parse-time-string
                 (timezone-make-date-arpa-standard date)))
         ;; ...
         )))

I was not familiar with `timezone-make-date-arpa-standard', and am not
familiar with "arpanet standard date" as a concept. It seems to
guarantee that some valid date string will be returned, but not
necessarily the one I would have guessed when time information is
missing:

    (timezone-make-date-arpa-standard "2017-03-29 3:05:00")
    ;=> "28 Mar 2017 20:05:00 -0700"
    (timezone-make-date-arpa-standard "2017-03-29")
    ;=> "31 Dec 1999 16:00:00 -0800"
    (timezone-make-date-arpa-standard "3/29/2016")
    ;=> "31 Dec 1999 16:00:00 -0800"

And sure enough:

    (equal (date-to-time "2017-03-29")
           (date-to-time "31 Dec 1999 16:00:00 -0800"))
    ;=> t

So it seems like it returns an arbitrary date if time elements are
missing?

        John

Re: Question about parse-time-string and date-to-time

[Eric Abrahamsen]

John Mastro <john.b.mastro@gmail.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>> A conundrum:
>>
>> parse-time-string accepts a string representing a date, and parses it
>> into a list of time elements, with nil for the unknowns.
>>
>> date-to-time calls parse-time-string and passes the result straight to
>> encode-time, to produce a time value.
>>
>> encode-time accepts series of time elements, and raises an error if any
>> of them are nil.
>>
>> I might be missing something, but I don't see how date-to-time could
>> ever work. Wouldn't it always have to replace the nils with zeros before
>> passing the result to encode time?
>
> It looks like, if the first call to `encode-time' signals an error, it
> re-tries using the result of calling `timezone-make-date-arpa-standard'
> on the original DATE argument:
>
>     (defun date-to-time (date)
>       (condition-case err
>           (apply 'encode-time (parse-time-string date))
>         (error
>          ;; ...
>          (apply 'encode-time
>                 (parse-time-string
>                  (timezone-make-date-arpa-standard date)))
>          ;; ...
>          )))
>
> I was not familiar with `timezone-make-date-arpa-standard', and am not
> familiar with "arpanet standard date" as a concept. It seems to
> guarantee that some valid date string will be returned, but not
> necessarily the one I would have guessed when time information is
> missing:
>
>     (timezone-make-date-arpa-standard "2017-03-29 3:05:00")
>     ;=> "28 Mar 2017 20:05:00 -0700"
>     (timezone-make-date-arpa-standard "2017-03-29")
>     ;=> "31 Dec 1999 16:00:00 -0800"
>     (timezone-make-date-arpa-standard "3/29/2016")
>     ;=> "31 Dec 1999 16:00:00 -0800"
>
> And sure enough:
>
>     (equal (date-to-time "2017-03-29")
>            (date-to-time "31 Dec 1999 16:00:00 -0800"))
>     ;=> t
>
> So it seems like it returns an arbitrary date if time elements are
> missing?

That's what I've found. If parse-time-string returns any nil values,
then you get 31 Dec, 1999. I'd rather get an error!