Change 825400 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Add timezone parameter to the edit registration endpoints

https://gerrit.wikimedia.org/r/825400

Change 825400 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Add timezone parameter to the edit registration endpoints

https://gerrit.wikimedia.org/r/825400

Enable event registration requires a timezone parameter and throws a 400 error if it is missing:

Enable event registration endpoint accepts correctly formatted timezone parameter:

Edit event registration endpoint displays 400 error on incorrectly formatted timezone parameter:

Edit event registration endpoint accepts correctly formatted timezone parameter. A few examples below:

CEST:

+4:45

Africa/Accra

API documentation is correctly updated.

One thing I found @Daimona - the timezone parameter will currently accept any random string for timezone as long as they start with a + or a -. Thoughts on this? A couple examples below:

In T315692#8306011, @vaughnwalters wrote:

One thing I found @Daimona - the timezone parameter will currently accept any random string for timezone as long as they start with a + or a -. Thoughts on this? A couple examples below:

Yuck, it definitely needs to be fixed.

OMG, PHP, what the frick are you even doing?

$timezone = '+ThisShouldProbablyThrowAnError';
var_dump(new DateTimeZone( $timezone ));

object(DateTimeZone)#1 (2) {
  ["timezone_type"]=>
  int(1)
  ["timezone"]=>
  string(6) "+00:00"
}

I'm... speechless... flabbergasted... worried... I think I'll have to drink something to forget about this obscenity. On the bright side, according to this 3v4l, they fixed this in PHP 8. Better late than never, I guess?

So yeah, I'm gonna add a workaround for this cool feature of PHP < 8.

Change 841193 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Work around PHP bug in timezone validation

https://gerrit.wikimedia.org/r/841193

Inspired by @vaughnwalters' tests @Daimona, I also tried something like "+99:62", the result in the DB was "+100:0", and then an error when trying to update it again:

"message": "Error: exception of type Exception: DateTimeZone::__construct(): Timezone must not contain null bytes"

In T315692#8319644, @cmelo wrote:

Inspired by @vaughnwalters' tests @Daimona, I also tried something like "+99:62", the result in the DB was "+100:0", and then an error when trying to update it again:

"message": "Error: exception of type Exception: DateTimeZone::__construct(): Timezone must not contain null bytes"

Dear PHP, this is becoming upsetting. This bug in particular was not fixed in later versions of PHP and still affects 8.2rc3. I've filed a bug report against php-src.

In T315692#8320837, @Daimona wrote:

In T315692#8319644, @cmelo wrote:

Inspired by @vaughnwalters' tests @Daimona, I also tried something like "+99:62", the result in the DB was "+100:0", and then an error when trying to update it again:

"message": "Error: exception of type Exception: DateTimeZone::__construct(): Timezone must not contain null bytes"

Dear PHP, this is becoming upsetting. This bug in particular was not fixed in later versions of PHP and still affects 8.2rc3. I've filed a bug report against php-src.

Thank you so much @Daimona!!!

Change 841193 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Work around PHP bugs in timezone validation

https://gerrit.wikimedia.org/r/841193

The bugs were worked around in the extension code. Additionally, the bug in the PHP interpreter was also fixed, and I think we'll see it in PHP 8.2 (which, for MW, is very distant).

✅ POST:
"timezone": "+99:62"

✅ POST:
"timezone": "+ThisThrowsAnErrorNow"

✅ PUT
"timezone": "+99:62"

✅ PUT
"timezone": "+ThisNowThrowsAnError"

@Daimona There is an error now when using "timezone": "CEST".

It correctly accepts the value in the API, but then when checking in the UI it displays a timezone offset of "+60:00"

After that I can enter timezone of +99:00 and it is accepted and displays in the UI.

And then I can enter +99:60 and it throws the exception error:

{
    "message": "Error: exception of type Exception: DateTimeZone::__construct(): Timezone must not contain null bytes",
    "exception": {
        "id": "64845587c2820565bc537977",
        "type": "Exception",
        "file": "/var/www/html/w/extensions/CampaignEvents/src/Event/Store/EventStore.php",
        "line": 248,
        "message": "DateTimeZone::__construct(): Timezone must not contain null bytes",
        "code": 0,
        "url": "/w/rest.php/campaignevents/v0/event_registration/7",
        "caught_by": "other",
        "backtrace": [
            {
                "file": "/var/www/html/w/extensions/CampaignEvents/src/Event/Store/EventStore.php",
                "line": 248,
                "function": "__construct",
                "class": "DateTimeZone",
                "type": "->"

etc etc etc

The same is true of negative offsets of -99:60. Here is a video to demonstrate (sorry for the poor quality - I had to greatly compress it to get it into phab) :

I should also note that if I enter +99:00, +99:62, or +99:60 in the UI it works correctly and changes the time to the max allowed of +14:00 - so this is only an issue with the API.

Change 844972 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Improve time zone validation and conversion

https://gerrit.wikimedia.org/r/844972

In T315692#8330710, @vaughnwalters wrote:

@Daimona There is an error now when using "timezone": "CEST".

It correctly accepts the value in the API, but then when checking in the UI it displays a timezone offset of "+60:00"

Whoops, I forgot to divide by 60; fixed in the patch above.

And then I can enter +99:60 and it throws the exception error:

A > should really have been a >=, fixed.

The same is true of negative offsets of -99:60.

Fixed together with the above.

Here is a video to demonstrate (sorry for the poor quality - I had to greatly compress it to get it into phab) :

(FYI, I can't see the video... You may need to attach it to the task or something)

I should also note that if I enter +99:00, +99:62, or +99:60 in the UI it works correctly and changes the time to the max allowed of +14:00 - so this is only an issue with the API.

Yeah, and FTR, the automatic rewrite of larger offsets to +14 is something I'd hope to fix in the future, see T320359.

Also, I've filed an issue against php-src to ask that the error handling be improved on their side: https://github.com/php/php-src/issues/9784.

Here is a video to demonstrate (sorry for the poor quality - I had to greatly compress it to get it into phab) :

(FYI, I can't see the video... You may need to attach it to the task or something)

Ah yeah, it's attached now

FTR, I came across another PHP bug here: https://bugs.php.net/bug.php?id=74671. Basically, PHP assumes that all time zone abbreviations do not have DST, and returns the wrong offset for those that do actually have DST. This was only fixed in recent versions, see https://3v4l.org/3rbNX, so I wrote a workaround.

Change 844972 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Improve time zone validation and conversion

https://gerrit.wikimedia.org/r/844972