binary protocol time representation

[Dan Farina]

>From the docs of the current protocol:

> Some commands involve a client sending some kind of expiration time
> (relative to an item or to an operation requested by the client) to
> the server. In all such cases, the actual value sent may either be
> Unix time (number of seconds since January 1, 1970, as a 32-bit
> value), or a number of seconds starting from current time. In the
> latter case, this number of seconds may not exceed 60*60*24*30 (number
> of seconds in 30 days); if the number sent by a client is larger than
> that, the server will consider it to be real Unix time value rather
> than an offset from current time.

Are we going to stick with this behavior? There was no discussion about
changing it, but perhaps its come time to consider nixing absolute
(epoch) time, unless someone has a reason to keep it. It costs the
client a minuscule bit of complexity and saves the server roughly the
same amount unless it has to do date conversion on some foreign platform
that doesn't make UNIX epoch time easily available.

My more detailed opinion:
The epoch time may have been much more useful when people were
telnetting into memcached, but since the binary protocol will probably
be used with program support (except in the case of masochists or subtle
bug hunters) I would suggest just picking a single representation to
reduce the "hair" on the protocol semantics. While the status-quo is
relatively harmless, I think a little discussion should be paid to this
issue while the new protocol gels.

Justification: Many programming environments use something other than
epoch time, and nowadays even C programmers are generally discouraged to
use it and instead opt for the time struct. Given that everyone has a
different way of slicing and dicing  dates (NTP, UNIX
Epoch, .NET/Microsoft "ticks", and a host of language-specific
libraries) the shortest-mean-distance computation for "number of seconds
in the future from time entered" is pretty easy for all involved and
even in the legacy case conversion from epoch time is of minuscule cost.

Finally, and possibly most importantly, seconds from entry time saves
you the annoying problems of time zones and daylight savings time*
without annoying/complexity-inducing time-zone+absolute time
representation schemes. Yuck!

df

* Something the server implementation /ought/ to be immune to