apc.use_request_time=0 default is confusing with update and confusing related to apc.php info page

[PauluzzNL]

Although architectually perhaps not the best implementation, we use the mtime given back from apcu_key_info compared to the current time() to do purges at certain moments.

With the update to APCu 5.1.22 our caching broke down and after a while I figured this was related to the changes made in #391.

A side-effect from this change is also that the times from apcu_key_info return different values. The apc.php info page also now provides confusing results. The access/modified/created at times return times in 1970 / 1971.

I'm not sure if this is the correct place to post this. However I feel that others might run into similar issues while upgrading. I assume it would help if the information page and/or the documentation on the info pages on php.net would reflect the different behavior if apc.use_request_time=0, or otherwise that these functions would keep returning the time in the way they did before.

If anything is unclear I can provide additional information.

[nikic]

I believe the problematic change here is actually eb28fe1, which switches to using a monotonic clock, which uses a different starting point than time(). I think this change needs to be reverted, it's pretty reasonable to assume that these are normal timestamps.

[nikic]

Change reverted in 8c05c51.

@remicollet Would you mind creating another release for this?

[TysonAndre]

1. It would be possible to store both the result of gettimeofday/time by adding a new struct field for the monotonic time to the cache entry. APIs could use a new field name or method name for returning the monotonic time and keep existing creation dates the same, and existing applications should continue working. (The web UIs could add another column for ttl or computed expiry of microtime(true) + ttl)
2. Idea: Increase granularity of expiry timestamps from 1 second to milliseconds/nanoseconds? #417 is related, if the way timestamps are tracked internally will be changed, APCu has the option to be more precise - time_t usually has precision of only seconds - https://en.cppreference.com/w/c/chrono/time_t

[jocel1]

Hi @remicollet!

It has been almost a year and no new release has been created with @nikic changes to disable the monotonic clock? :)

Thanks!

[walter-exit]

Hi @remicollet!

It has been almost a year and no new release has been created with @nikic changes to disable the monotonic clock? :)

Thanks!

I, too, would greatly appreciate it if it were reverted to the way it was before, back to the epoch, and no longer monotonic. Or at least if monotonic was only used internally, but the entry details would return epoch, even if it is in milliseconds instead of seconds.

For others, if it helps; to display times in a "human readable" way no matter your APC-config, you could use:

`function convert_apc_time_to_human($apc_item_time, $output_format='Y-m-d H:i:s'){
if(ini_get('apc.use_request_time')==='1'){
// APC-config is using epoch
return date($output_format,$apc_item_time);
}else{
// APC-config is using monotonic
return date($output_format,$apc_item_time+time()-hrtime()[0]);
}
}

$cache_info = apcu_cache_info();
forEach($cache_info['cache_list'] as $n=>$apcu_entry) {
$human_readable_mtime = convert_apc_time_to_human($apcu_entry['mtime']);
$human_readable_creation_time = convert_apc_time_to_human($apcu_entry['creation_time']);
$human_readable_access_time = convert_apc_time_to_human($apcu_entry['access_time']);
}`

[nesl247]

5.1.23 was released last year with the revert.