Discourage use `current_time( 'timestamp' )`

[Rarst]

Is your feature request related to a problem?

current_time() with timestamp or U format produces a "WordPress timestamp", a sum of Unix timestamp and current time zone offset.

While historically entrenched in core, the use of such timestamps is deeply problematic and we are working on eliminating them in favor of real Unix timestamps and full interoperability with PHP.

Describe the solution you'd like

• current_time( 'timestamp', true ) / current_time( 'U', true ) are equivalent to time() and should be replaced with it
• current_time( 'timestamp' ) / current_time( 'U' ) should be discouraged in favor of requesting non-timestamp format, or otherwise refactoring the usage

Additional context (optional)

The use of current_time( 'timestamp' ) had been mostly eliminated from core in #40657. Minimal usage in unit tests and older functions that must operate with WP timestamps for backwards compatibility reasons remains.

[GaryJones]

Just because I missed the emphasis here on first read - the bad thing here isn't the use of current_time(), but more the use of the first arg being timestamp.

[Rarst]

Yes, current_time() works fine for other formats (now, after round of fixes).

[jrfnl]

I'm working on adding this check. I'm inclined to add it to the TimezoneChange sniff as all date/time related function checks are then contained in one sniff, though this one needs quite some additional logic.
Alternatively I could add a stand-alone sniff, WP.CurrentTimeTimeStamp maybe ?

Opinions ?

[Rarst]

I think (hope) we head towards formally deprecating WP timestamps in the future, so it might make more sense to combine issues related to them as separate sniff. Would make it more convenient down the road to handle them as a separate unit of mess.

PS "timestamp" is a single word traditionally in computing context, so CurrentTimeTimestamp for name then :)

[jrfnl]

@Rarst Can you clarify what you mean ? You seem to contradict yourself in yes/no separate sniffs or not.

As an alternative, I was just thinking, we could also create a separate DateTime category, similar to the DB.

So to summarize the choice we have to make for this issue + #1794 :

• Do we want to have all the checks for Date/Time related issues in one sniff ? or in separate sniffs ?
• If separate sniffs: should those all be placed in a new DateTime category to make them easier to find/manage ?
• If the same sniff, the TimeZoneChange sniff would be the one, but the name would no longer fit the function, so what should be the new name for that sniff ?

Either way, looks like the WP.TimeZoneChange will need to be deprecated in 2.2.0 and be removed in 3.0.0.

[Rarst]

Messed up timezones and messed up timestamps are different problems (and current_time('timestamp') would be one specific aspect of one problem), though they are both within Date/Time component.

So the hierarchy as I see it would go like:

• Date/Time component
  • use of WP timestamps
    • current_time() returns WP timestamp
  • setting time zone to UTC on WP boot
    • date_default_timezone_set() breaks things

I don't have a strong opinion how that should be organized within PHP CS mechanics.