TypeError: Unsupported operand types: string * int *

[nurielmeni]

Path: /wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php
File: class-wp-rest-posts-controller.php
Line: 1833

Expression Error: get_option('gmt_offset') * HOUR_IN_SECONDS
Rais Exception: TypeError: Unsupported operand types: string * int

Suggested Fix: intval(get_option('gmt_offset')) * HOUR_IN_SECONDS

Thanks

[sabernhardt]

Hi and thanks for the ticket!

WP_REST_Posts_Controller::prepare_item_for_response() probably needs the same change as the current_time() function in #57035. Note: the offset is not always an integer (#57998).

[nihar007]

Patch added. I added intval function

[mhshohel]

Implemented a patch to perform a type cast on 'gmt_offset'. Additionally, incorporated a standard practice by introducing a default value of 0.

[mhshohel]

Resolved the problem of unsupported operand types: string * int *. Additionally, adhered to the standard practice by setting 0 as the default value.

[rleeson]

GMT offsets can be fractional, as noted in this ticket 57035 comment so intval or casting to an int cause regression for those fractional time zones.

[sabernhardt]

Reopening, as this would need a (new) patch that considers fractional offsets.

Previously, using the function or casting to to convert the GMT offset to a fractional decimal number could cause regression problems for fractional timezones. Now, we use the function to correctly convert the GMT offset to a decimal number. This resolves the issue of incorrect conversion of fractional timezones. fixes:

Trac ticket: https://core.trac.wordpress.org/ticket/58986

props marcio-zebedeu

[rleeson]

Add common retrieval for GMT offset as a float with default of 0.

[rleeson]

• New method added current_gmt_offset which reads the offset and type casts to float, with a default of 0.
• Replaced all Core instances of get_option( 'gmt_offset' ) with the function to guarantee a float in every instance, avoiding type cast issues/errors.
• Added Unit Tests to the date and datetime groups
• Also addresses ticket #57035.

This patch is here.

Edge cases of a missing/invalid GMT offset can cause type casting error. Additionally, Core contained multiple direct calls to retrieve this option with an inconsistent usage and an apparent misconception in some resolutions that the offset was an integer, where it is actually a float/double.

To address the issue, I added current_gtm_offset to ensure a valid float, with default offset of 0, and further replaced all instances of the direct data retrieval with this function as a proxy.

Trac tickets: Ticket #58986 and Ticket # 57035

[oglekler]

This ticket was discussed during a bug scrub.

It needs testing and dev review. Please check that Unit tests are covering all possible cases.

Add props: @mukesh27

[nicolefurlan]

This ticket was discussed in today's bug scrub.

We decided to move this (and #57035) to 6.5. Per @hellofromTonya:

I'm concerned about both of these tickets going in this late in the release due to the lack of test coverage and testing. Why? Casting with inval() for the one and (float) for the other may have side effects. Thinking it needs a contextual dive into how the code got to the current state to avoid potentially introducing a regression.

@SergeyBiryukov or @rarst if you have time to review and have confidence in this fix, don't hesitate to pull it back into the 6.4 milestone.

Props to @hellofromTonya :)

[chaion07]

Hello @nurielmeni and thanks for reporting this. We reviewed this ticket during a recent bug-scrub session here's the summary of the feedback received:

1. We would want to check with @SergeyBiryukov if you have time to review this or we should move this to Future Release.
2. We would also want to understand what additional test coverage would be helpful to increase confidence enough (P.S. we realized that the patches already include more tests, so understanding what would be helpful to add might be useful for folks working on it)

Cheers!

Props to @mikeschroder & @mukesh27

[rajinsharwar]

Seems like this is on punt mode form 6.4, and is pending some decisions from the component maintainers.
https://core.trac.wordpress.org/ticket/58986#comment:13

Unfortunately, we might need to punt this to a Future Release until we have some activity on this.

Props to @hellofromTonya!

[verygoode]

Found this while reviewing another ticket

A related report where /wp-admin/options.general.php can break https://core.trac.wordpress.org/ticket/56358#comment:6

Another similar report, https://core.trac.wordpress.org/ticket/60629

[hellofromTonya]

I think this ticket goes with #57035.

As I noted in [57035#comment:39]:

I'm thinking this area needs a deeper contextual dive as well as consideration and testing to raise confidence of no side effects or regressions being introduced. It'll also need more test coverage (happy and unhappy paths).

The challenges:

• robust solution to handle all timezones include partial hour timezones.

  The gmt_offset can be a float/double for partial-hour timezones such as +5:30 UTC for India and Sri Lanka.
  

• review of what values gmt_offset should and could have.
• and cross-version compatibility for the PHP versions WP supports.

I'm also curious of how this is solved in other projects.

Pulling it into 6.7 and self-assigning with intent to help shepherd the effort for this ticket and #57035.

Also marking the current patches as changes-requested as there's more work to do. That said, I'm yet convinced any of the patches are the way forward. I think that's the place to start -> figure out the way forward and then build a patch for it.

[hellofromTonya]

Related: #56358, #57035, #60629.

All of these tickets are dealing with the same underlying issue.

[peterwilsoncc]

I've created a ​PR for this and the related tickets to cast the gmt offset throughout the code base. I'm happy to hear suggestions for alternative approaches too.

[hellofromTonya]

​PR 7233 is ready for commit. Spoke with @peterwilsoncc who will do the commit.

Copying my approval in the PR:

[As I previously noted](​https://github.com/WordPress/wordpress-develop/pull/7233#issuecomment-2327431927), this baby step resolves the immediate issue and uses the existing pattern committed in https://core.trac.wordpress.org/changeset/58923.

Ideally these changes would have full test coverage. That said, in talking with @peterwilsoncc, he shared:

The tests are there for current features and the upgrade tests should catch anything in the ugrade routine

Getting this committed early enough gives a longer soak time to hopefully uncover any issues.

I think this is ready enough for commit ✅

[peterwilsoncc]

In 59064:

Date/Time, PHP Compat: Prevent type errors using GMT offset option.

Prevents a potential type errors when making use of the gmt_offset option by casting the value to a float prior to performing calculations with the value.

This mainly accounts for incorrect storage of values, such as an empty string or city name.

Follow up to [58923].

Props chaion07, hellofromtonya, kirasong, mhshohel, mukesh27, nicolefurlan, nihar007, nurielmeni, oglekler, peterwilsoncc, prionkor, rajinsharwar, rarst, rleeson, sabernhardt, SergeyBiryukov, swissspidy, toastercookie, verygoode.
Fixes #56358, #58986, #60629.