lcobucci/clock

Yet another clock abstraction

Hi there 👋

For many years I've been contributing to the PHP ecosystem by creating and supporting libraries that make our lives easier.

I've collected a good set of production-grade libraries and experiments, which you may use and contribute to!

Some info about my work

There are so many opinions when it comes to Open Source Software. To clarify my PoV on it, I wrote these pieces:

• Why do I do Open Source Software?
• What's my policy on version support?

clock's Issues

Require PHP 7.2

Add QA tools

PHPStan, Infection, etc.

Question: Clock usage in entities

A common pattern I use is storing timestamps like createdAt, processedAt, etc etc type datetimes in an entity like the following:

class Acme
{
  private $createdAt;
  private $processedAt;

  public function __construct() {
    $this->createdAt = new \DateTimeImmutable();
  }

  public function process(): void {
    $this->processedAt = new \DateTimeImmutable();
  }
}

I'm curious how you normally would approach a situation like this for your entities?

It feels a bit clunky to pass in a Clock object to my entities to record the time something happened:

class Acme
{
  private $createdAt;
  private $processedAt;

  public function __construct(Clock $clock) {
    $this->createdAt = $clock->now();
  }

  public function process(Clock $clock): void {
    $this->processedAt = $clock->now();
  }
}

Seems like a supplemental global helper and/or singleton which would allow you to swap implementations during testing would be a big help in DX/ergonomics for this library.

e.g.

function clock(array $params = []): Clock {
  static $clock;
  if (isset($params['globalClock'])) {
   $clock = $params['globalClock'];
  }
  if (!$clock) {
    $clock = new SystemClock();
  }
  return $clock;
}

This would then allow easily access to the clock globally, but also allow for swapping different implementations at runtime.

Consider different abstraction

Instead of clock it's maybe more interesting to see time as stream of timestamps. So each next timestamp will be "now" or just same time stamp.

Minor version update to 1.2 adds breaking change (php 7.2)

A minor version shouldn't, in theory, cause breaking changes, but increasing the requirement to PHP 7.2 (while defensible) breaks existing installs. I think it's a great idea to keep up to date with the latest but lots of builds are still using 7.1.

Is PHP 7.2 requirement really necessary?

Hello!

With recent php version bump to 7.2 you broke lcobucci/jwt's master branch (for PHP 7.1). I guess you'll bump up PHP version for jwt package too.

However, I don't see any PHP 7.2 specific feature in lcobucci/clock. Maybe you can release v2.0 with PHP 7.2+ requirement, but leave v1.* with PHP 7.1.

What do you think?

P.S. https://github.com/lakiboy/damax-api-auth-bundle is no longer working with PHP 7.1. :(

Remove dependency on system time zone

I'll just continue the discussion about UTC from #31 here....

I was just thinking why SystemClock::forUTC() over SystemClock::UTC() and my thought is that you will never need two instances of SystemClock with UTC timezone and so this instance can be self hosted in a static private property, in which case having just UTC() seems more reasonable to me.

private static ?SystemClock $utcClock = null;
public static function UTC(): SystemClock
{
  if (self::$utcClock === null) {
    self::$utcClock = new SystemClock(new \DateTimeZone('UTC'));
  }
  return self::$utcClock;
}

FrozenClock::fromUTC(): FrozenClock
{
  return new self(SystemClock::UTC()->now());
}

As for the BC break with nonnullable timezone in SystemClock constructor, it can be made deprecated in when SystemClock::(for)UTC() is added, and to be removed in 2.0

Consider tagging v1.1.1

There have been 3 merged PRs since the last release back in January. Please consider releasing a new minor version 🙂

DateTimeZone

hi ,
in my laravel app after login to get user information get the below error:
'syntax error, unexpected identifier "DateTimeZone", expecting variable'
vendor/lcobucci/clock/src/SystemClock.php line 13
my timezone Asia/Tehran

PHP 5.6

I'd like to use this in a (Wikimedia) project that for silly reasons is using something in between PHP 5.6 and 7.0. Hence I can't without a PHP 5.6 compatible version.

This component states that it needs 7.2 but it looks like it is 7.1 compatible. Also looks like a 5.6 version can be created by removing some type hints. Is a PR that creates such a version welcome?

Use lcobucci/coding-standard

Dependency hell - make the PHP requirement less strict ~8.2.0

This package is very popular and has a large number of packages dependent on it. But at the same time it has very strict php requirement >= 8.2.0, < 8.3.0. If I want to test my project (which depends on lcobucci/clock) on PHP 8.3 I won't be able to do it now. If I need to support different PHP version 7.4-8.2, I'll have a problem too. Also composer may downgrade this package to 2.2.0 on php 8.3.
Since there should be no backwards compatibility breaks until php 9.0, can you fix php requirement?

- ~8.2.0
+ ^8.2
#or 
+ >=8.2 

PHP 8.2 dependency

Hi!

I wanted to check if you actually require PHP ~8.2.0 with the last release or if this was an accident.
Because currently our minimum PHP version is 8.1 and we have yet other dependencies which won't work for 8.2.

https://github.com/lcobucci/clock/blob/3.2.x/composer.json#L13

Thank you for your hard work!
With kind regards,
Philipp

PHP 8.3 Support

What's the plan to provide support for PHP 8.3, which is scheduled for release on November 23, 2023, with the first RC version set to be release on August 31, 2023.

Syntax error, unexpected 'private' (T_PRIVATE), expecting variable (T_VARIABLE)

Syntax error, unexpected 'private' (T_PRIVATE), expecting variable (T_VARIABLE)
On clock/src/SystemClock.php

Update from PHP 8.1 to PHP 8.3

Hi, I am using lcobucci/clock:3.0.0 with PHP 8.1. Now I'm trying to upgrade to PHP 8.3 and I'm getting the problem

composer why-not php ^8.3
Package "php" could not be found with constraint "^8.3", results below will most likely be incomplete.
lcobucci/clock 3.0.0 requires php (~8.1.0 || ~8.2.0) 

Do I understand correctly, given the PHP dependencies https://github.com/lcobucci/clock/blob/3.0.x/composer.json#L13 I need to upgrade to PHP 8.2. Then upgrade lcobucci/clock to version 3.2.0 because it supports PHP 8.2 and 8.3 https://github.com/lcobucci/clock/blob/3.2.x/composer.json#L13. And thereafter I can upgrade to PHP 8.3.

I don't see any critical code changes that would forbid me from using version 3.0.0 with PHP 8.3
3.0.x...3.3.x

I think it would be great if version 3.0.0 (or 3.0.1) depended on php >= 8.1

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency phpunit/phpunit to v11

Detected dependencies

composer

composer.json

• php ~8.2.0 || ~8.3.0
• psr/clock ^1.0
• infection/infection ^0.29
• lcobucci/coding-standard ^11.0.0
• phpstan/extension-installer ^1.3.1
• phpstan/phpstan ^1.10.25
• phpstan/phpstan-deprecation-rules ^1.1.3
• phpstan/phpstan-phpunit ^1.3.13
• phpstan/phpstan-strict-rules ^1.5.1
• phpunit/phpunit ^10.2.3

github-actions

.github/workflows/backwards-compatibility.yml

• actions/checkout v4
• shivammathur/setup-php 2.31.1
• actions/cache v4.0.2

.github/workflows/coding-standards.yml

• actions/checkout v4
• shivammathur/setup-php 2.31.1
• actions/cache v4.0.2

.github/workflows/composer-json-lint.yml

• actions/checkout v4
• shivammathur/setup-php v2
• actions/cache v4

.github/workflows/mutation-tests.yml

• actions/checkout v4
• shivammathur/setup-php 2.31.1
• actions/cache v4.0.2
• codecov/codecov-action v4.5.0

.github/workflows/phpunit.yml

• actions/checkout v4
• shivammathur/setup-php 2.31.1
• actions/cache v4.0.2
• actions/checkout v4
• shivammathur/setup-php 2.31.1
• actions/cache v4.0.2

.github/workflows/release-on-milestone-closed.yml

• actions/checkout v4
• laminas/automatic-releases 1.24.0
• laminas/automatic-releases 1.24.0
• laminas/automatic-releases 1.24.0
• laminas/automatic-releases 1.24.0
• laminas/automatic-releases 1.24.0

.github/workflows/static-analysis.yml

• actions/checkout v4
• shivammathur/setup-php 2.31.1
• actions/cache v4.0.2

---

• Check this box to trigger a request for Renovate to run again on this repository

Dependency lock on PHP 8 breaks other PHP 7.* compatible packages

The new dependency on PHP 8 is breaking compatibility with older PHP versions on other packages such as league/oauth2-server.
This change should have probably been done on a major version, if this package should be seen as SemVer compatible.

Any package requiring this one or depending on the JWT package will breakm when allowing automatic minor version upgrades.