Requesting RFC karma

9 months ago by Hans Henrik Bergan — view source

unread

My name is "Hans Henrik Bergan", usually go by the nickname
"divinity76", I've contributed to OSS (including PHP) for years, and
am currently involved in 3 things that might require an RFC, and
requesting RFC karma for wiki account "divinity76".

1/3: adding BLAKE3 to PHP, a very fast cryptographically secure
hash: https://github.com/php/php-src/pull/13194

2/3: int|float for sleep, sleep(0.1) => sleep 0.1 seconds:
https://github.com/php/php-src/pull/13401

3/3: int|float for DateTime::setTimestamp, setTimestamp(0.123456) =>
1970-01-01 00:00:00.123456 : https://github.com/php/php-src/pull/13383

9 months ago by Ilija Tovilo — view source

unread

Hi Hans

My name is "Hans Henrik Bergan", usually go by the nickname
"divinity76", I've contributed to OSS (including PHP) for years, and
am currently involved in 3 things that might require an RFC, and
requesting RFC karma for wiki account "divinity76".

RFC karma was granted, good luck!

Ilija

9 months ago by Hans Henrik Bergan — view source

unread

My name is "Hans Henrik Bergan", usually go by the nickname
"divinity76", I've contributed to OSS (including PHP) for years, and
am currently involved in 3 things that might require an RFC, and
requesting RFC karma for wiki account "divinity76".

1/3: adding BLAKE3 to PHP, a very fast cryptographically secure
hash: https://github.com/php/php-src/pull/13194

2/3: int|float for sleep, sleep(0.1) => sleep 0.1 seconds:
https://github.com/php/php-src/pull/13401

3/3: int|float for DateTime::setTimestamp, setTimestamp(0.123456) =>
1970-01-01 00:00:00.123456 : https://github.com/php/php-src/pull/13383

and possibly
4/4: automatic code formatting check for pull requests:
https://github.com/php/php-src/pull/13417

9 months ago by Marc Bennewitz — view source

unread

Hi Hans,

My name is "Hans Henrik Bergan", usually go by the nickname
"divinity76", I've contributed to OSS (including PHP) for years, and
am currently involved in 3 things that might require an RFC, and
requesting RFC karma for wiki account "divinity76".

3/3: int|float for DateTime::setTimestamp, setTimestamp(0.123456) =>
1970-01-01 00:00:00.123456 : https://github.com/php/php-src/pull/13383

Actually I also want to work on this if I find time ... but as this is a
BC break I think it makes sense to revisit DateTime (and friends) to
bundle BC breaks to a single PHP version - probably PHP 9 and more sure
there is a way for users to make it work in PHP (7+)8+9.

Personal and incomplete list I think needs improvements:

allow float for setTimestamp
option to return timestamp as float to simplify passing it to JS
Missing getter/setter for most of the date/time parts like
get/setSecond, get/setHour etc.
* For now I only added get/setMicroseconds together with
createFromTimestamp because
DateTime::createFromTimestamp(123456789)->setMicroseconds(123987)
* After thinking about naming - I think this should be renamed to
singular 😬
Add missing methods to DateTimeInterface
Allow userland implements DateTimeInterface
* Define how createFromInterface behaves on userland implementations
fixing ISO 8601 format
fixing some return type definitions from self to static
strict mode
* DateTime::createFromFormat('Y-m-d', '2023-02-29')
* DateTime::createFromFormat('Y-m-d H:i', '2024-03-31 02:30', new DateTimeZone('Europe/Berlin'))
Missing current microseconds on createFromFormat but other non
defined parts needs to be explicitly reset using |!
leap seconds support on UTC TZ
* As of leap seconds ... wouldn't it be better to default to +00:00
instead of UTC ?
Support nanoseconds

I'm for sure not able to work on all these points and that's why I only
started very small close to no BC improvements without RFC.

Marc

9 months ago by Derick Rethans — view source

unread

Hi Hans,

My name is "Hans Henrik Bergan", usually go by the nickname
"divinity76", I've contributed to OSS (including PHP) for years, and
am currently involved in 3 things that might require an RFC, and
requesting RFC karma for wiki account "divinity76".

3/3: int|float for DateTime::setTimestamp, setTimestamp(0.123456) =>
1970-01-01 00:00:00.123456 : https://github.com/php/php-src/pull/13383

Actually I also want to work on this if I find time ... but as this is a BC break I think it makes sense to revisit DateTime (and friends) to bundle BC breaks to a single PHP version - probably PHP 9 and more sure there is a way for users to make it work in PHP (7+)8+9.

Personal and incomplete list I think needs improvements:

allow float for setTimestamp

option to return timestamp as float to simplify passing it to JS

Missing getter/setter for most of the date/time parts like get/setSecond, get/setHour etc.
* For now I only added get/setMicroseconds together with createFromTimestamp because DateTime::createFromTimestamp(123456789)->setMicroseconds(123987)
* After thinking about naming - I think this should be renamed to singular 😬

Add missing methods to DateTimeInterface

Allow userland implements DateTimeInterface
* Define how createFromInterface behaves on userland implementations

fixing ISO 8601 format

fixing some return type definitions from self to static

strict mode
* DateTime::createFromFormat('Y-m-d', '2023-02-29')
* DateTime::createFromFormat('Y-m-d H:i', '2024-03-31 02:30', new DateTimeZone('Europe/Berlin'))

Missing current microseconds on createFromFormat but other non defined parts needs to be explicitly reset using |!

leap seconds support on UTC TZ
* As of leap seconds ... wouldn't it be better to default to +00:00 instead of UTC ?

Support nanoseconds

I'm for sure not able to work on all these points and that's why I only started very small close to no BC improvements without RFC.

Marc

IMO, doing tweaks to this base functionality isn't the way forwards. I've been having on and off conversations with Florian over the last couple of months to see if we can design a better higher level API instead of patching the nits.

cheers
Derick

9 months ago by Marc Bennewitz — view source

unread

Hi Hans,

My name is "Hans Henrik Bergan", usually go by the nickname
"divinity76", I've contributed to OSS (including PHP) for years, and
am currently involved in 3 things that might require an RFC, and
requesting RFC karma for wiki account "divinity76".

3/3: int|float for DateTime::setTimestamp, setTimestamp(0.123456) =>
1970-01-01 00:00:00.123456 :https://github.com/php/php-src/pull/13383
Actually I also want to work on this if I find time ... but as this is a BC break I think it makes sense to revisit DateTime (and friends) to bundle BC breaks to a single PHP version - probably PHP 9 and more sure there is a way for users to make it work in PHP (7+)8+9.

Personal and incomplete list I think needs improvements:

allow float for setTimestamp

option to return timestamp as float to simplify passing it to JS

Missing getter/setter for most of the date/time parts like get/setSecond, get/setHour etc.
* For now I only added get/setMicroseconds together with createFromTimestamp because DateTime::createFromTimestamp(123456789)->setMicroseconds(123987)
* After thinking about naming - I think this should be renamed to singular 😬

Add missing methods to DateTimeInterface

Allow userland implements DateTimeInterface
* Define how createFromInterface behaves on userland implementations

fixing ISO 8601 format

fixing some return type definitions from self to static

strict mode
* DateTime::createFromFormat('Y-m-d', '2023-02-29')
* DateTime::createFromFormat('Y-m-d H:i', '2024-03-31 02:30', new DateTimeZone('Europe/Berlin'))

Missing current microseconds on createFromFormat but other non defined parts needs to be explicitly reset using |!

leap seconds support on UTC TZ
* As of leap seconds ... wouldn't it be better to default to +00:00 instead of UTC ?

Support nanoseconds

I'm for sure not able to work on all these points and that's why I only started very small close to no BC improvements without RFC.

Marc

IMO, doing tweaks to this base functionality isn't the way forwards. I've been having on and off conversations with Florian over the last couple of months to see if we can design a better higher level API instead of patching the nits.

Do you mean adding an additional API in C or userland? Is there a way to
participate on the discussion?

cheers
Derick

Best,
Marc

9 months ago by Derick Rethans — view source

unread

Hi Hans,

My name is "Hans Henrik Bergan", usually go by the nickname
"divinity76", I've contributed to OSS (including PHP) for years, and
am currently involved in 3 things that might require an RFC, and
requesting RFC karma for wiki account "divinity76".

3/3: int|float for DateTime::setTimestamp, setTimestamp(0.123456) =>
1970-01-01 00:00:00.123456 :https://github.com/php/php-src/pull/13383
Actually I also want to work on this if I find time ... but as this is a BC break I think it makes sense to revisit DateTime (and friends) to bundle BC breaks to a single PHP version - probably PHP 9 and more sure there is a way for users to make it work in PHP (7+)8+9.

Personal and incomplete list I think needs improvements:

allow float for setTimestamp

option to return timestamp as float to simplify passing it to JS

Missing getter/setter for most of the date/time parts like get/setSecond, get/setHour etc.
* For now I only added get/setMicroseconds together with createFromTimestamp because DateTime::createFromTimestamp(123456789)->setMicroseconds(123987)
* After thinking about naming - I think this should be renamed to singular 😬

Add missing methods to DateTimeInterface

Allow userland implements DateTimeInterface
* Define how createFromInterface behaves on userland implementations

fixing ISO 8601 format

fixing some return type definitions from self to static

strict mode
* DateTime::createFromFormat('Y-m-d', '2023-02-29')
* DateTime::createFromFormat('Y-m-d H:i', '2024-03-31 02:30', new DateTimeZone('Europe/Berlin'))

Missing current microseconds on createFromFormat but other non defined parts needs to be explicitly reset using |!

leap seconds support on UTC TZ
* As of leap seconds ... wouldn't it be better to default to +00:00 instead of UTC ?

Support nanoseconds

I'm for sure not able to work on all these points and that's why I only started very small close to no BC improvements without RFC.

IMO, doing tweaks to this base functionality isn't the way forwards. I've been having on and off conversations with Florian over the last couple of months to see if we can design a better higher level API instead of patching the nits.

Do you mean adding an additional API in C or userland? Is there a way to participate on the discussion?

A bit of both, I suppose. But mainly for a user facing API. I've nothing concrete yet, and will soon start collecting thoughts. I'll make sure to email this list.

cheers
Derick