Session values greater than 30 days expire immediately.

[ianmaddox]

Sessions with session.gc_maxlifetime greater than 2,592,000 expire immediately because the value is interpreted as a unix timestamp. Setting a gc_maxlifetime of 2,678,400 (31 days) will result in no sessions being stored because the driver is telling memcached to expire the key 1970-02-01 12:00:00am UTC.

[mkoppanen]

I am unsure if you are reporting a bug or describing current behaviour. From Memcached documentation:

"Expiration times can be set from 0, meaning "never expire", to 30 days. Any time higher than 30 days is interpreted as a unix timestamp date. If you want to expire an object on january 1st of next year, this is how you do that"

https://code.google.com/p/memcached/wiki/NewProgramming#Expiration

[ianmaddox]

I'm definitely reporting a bug. Before this commit in 2.0.0b2, session.gc_maxlifetime was always treated as a relative value because php-memcached added time(null) to whatever number you entered.

This problem is exclusive to session.gc_maxlifetime and does not effect normal userland cache interactivity which should indeed use memcache's 30 day threshold as expected. There is no reasonable use case for a cache TTL being automatically translated into a value that expired 45 years ago, and I haven't come up with a decent use case for a fixed gc_maxlifetime value that indicates all sessions will stop working at a fixed time in the future.

I am aware of no other session handler that treats session.gc_maxlifetime as a unix timestamp. Memcache shouldn't be the only one.

The reason this bug is only coming to light for me now is that Ubuntu 14.04 is the first LTE to use Memcache 2.x.

[sodabrew]

Fixed in upcoming release of php-memcached 3.0.0