Skip to content

Refactor basic time usages #19202

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

marc-mabe
Copy link
Contributor

@marc-mabe marc-mabe commented Jul 21, 2025

This refactors the internal usages of the current time.

  • Introduced zend_time.h to be used instead of system time.h
  • Added zend_realtime_spec as a wrapper around clock_gettime, timespec_get, gettimeofday and time using the real/wall clock providing a timespec with up to nanosecond resolution
  • Added zend_realtime_get as a replacement for time but optionally providing nanosecond
  • Added zend_monotime_fallback either pointing to zend_hrtime or wrapping zend_realtime_spec
    • this can be used for time measurements (like timeout handling) where a monotonic timer is preferable but a fallback to real/wall-time without high resolution requirement is still better than nothing
  • Added helper macros for working with timeval and timespec
  • Replace direct usages of the system time API with zend_realtime_* / zend_monotime_fallback
  • migrate to timespec for current time but keep timeval as it's needed for file/streams

As a result:

  • The code is better readable because system differences are encapsulated
  • zend_realtime_get / zend_realtime_spec and zend_monotime_fallback will be available for sure because it falls back clock_gettime -> timespec_get -> gettimeofday -> time
  • Y2038 problem of WIN64 due to long of timeval.tv_sec should be fixed time() and friends have Y2038 problem on 64 Windows #17856
  • Increased time resolution of microtime() / gettimeofday(true) without BC break
  • uniqid refactored a bit to not wait for the next time but increments if the current time is less or equal to the previous call. This should be faster and resolve a theoretical issue if the real time got modified in between

Even thought gettimeofday may not be available it wasn't checked everywhere before and compiling would have been failed already if missing. Availability should now be checked but as it falls back and it must have been available before I removed the conditions around microtime, gettimeofday and uniqid

@marc-mabe marc-mabe force-pushed the current_time_wrapper branch 4 times, most recently from 9ac29ea to b08662a Compare July 24, 2025 15:43
@marc-mabe marc-mabe force-pushed the current_time_wrapper branch 9 times, most recently from a7e9c3f to db6170e Compare July 25, 2025 07:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

time() and friends have Y2038 problem on 64 Windows
1 participant