[PATCH 2/2] Add std.rfc1123() to convert a formatted datetime to VCL_TIME

Federico Schwindt fgsch at lodoss.net
Tue Dec 16 00:13:28 CET 2014


Sure, nothing prevents it but do we want to support it?

The time in "Mon Dec 15 20:11:04 UTC 2014" is the representation of a time
in a string context. "1418674264" is just a number without any meaning
attached to it.
What stops us converting "1" to "Thu Jan  1 01:00:01 1970" if we were to
support such conversion? When will the fallback be used if passing any
number will return a TIME?

At the end of the day I just want to have a way to convert a date as being
used in the HTTP protocol to something useful.
While there might be some people wanting to use a timestamp directly we
already have some ways to do it and is not particularly standard.

If you still want to use time() fine, modifying the patch is rather
trivial. I'm just not fond of using that name because I don't think it
should support a timestamp.


On Mon, Dec 15, 2014 at 8:12 PM, Poul-Henning Kamp <phk at phk.freebsd.dk>
wrote:
>
> --------
> In message <
> CAJV_h0YFuL+OMcFckxAd+D9noX__aPRyLK17WA4m5Cm6f-XdQg at mail.gmail.com>
> , Federico Schwindt writes:
>
> >I thought about this and decided to go for rfc1123() as time() would
> >indicate a TIME input with .integer(), .ip() and .real().
>
> I simply don't grok that.
>
> The idea behind the conversion functions is
>
>         std.${typename}(${convert_this}, ${use_this_if_you_cant})
>
> Nothing prevents
>
>         std.time("Mon Dec 15 20:11:04 UTC 2014", std.now())
> and
>         std.time("1418674264", std.now())
>
> from giving the same result ?
>
> >The other options I had in mind were datetime() and date() but I liked
> >rfc1123() best.
>
> I really hate rfc1123 as a name...
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20141215/2eb25177/attachment.html>


More information about the varnish-dev mailing list