Re: Requesting RFC karma

On 20.02.24 09:58, Derick Rethans wrote:

On 20 February 2024 08:41:19 GMT, Marc Bennewitz<marc@mabe.berlin> wrote:

Hi Hans, On 16.02.24 13:05, Hans Henrik Bergan wrote:

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

Attachment: [application/pgp-keys] OpenPGP public key OpenPGP_0x3936ABF753BC88CE.asc
Attachment: [application/pgp-signature] OpenPGP digital signature OpenPGP_signature.asc