my LC_TIME is "nb_NO.UTF8", and $format is "%A %d. %B" and $timestamp is 1655935200 and strftime() gives me "torsdag 23. juni", but \PHP81_BC\strftime gives me "Thursday 23. June"

.. any idea what went wrong here? reproduce script:

<?php
require_once('vendor/autoload.php');
if(false === setlocale(LC_TIME, "nb_NO.UTF8")){
 die("error: locale nb_NO.UTF8 is not installed");
}
$stamp = 1655935200;
$format = "%A %d. %B";
var_dump(\PHP81_BC\strftime($format, $stamp));
var_dump(strftime($format, $stamp));

outputs on my system (PHP7.4.29):

root@75cee9b6f638:/var/www# php test.php
string(17) "Thursday 23. June"
string(16) "torsdag 23. juni"

what went wrong here?

This implements a mechanism to replace the locale aware part of the function with differrent formatter classes.

For now it simply implements a fallback to a non-locale aware formatting using DateTime->format() when the intl extension is missing. Future extension could implement making use of strftime() if it still exist or implement locale formatting in pure PHP.

For testing a environment variable STRFTIME_NO_INTL can be set to force using the fallback.

Currently the test for the gregorian calendar jump fails, but I don't understand the issue well enough to fix it.

I noticed the code is currently using a somewhat uncommon formatting (partly enforced via editor config). Would it make sense to adopt PSR-12? I'm happy to provide a pull request if wanted.

Currently, the composer.json lists a minimum PHP version of 5.6, but the actual code includes many features which require later versions, such as a type declaration of ?string, which is only valid since PHP 7.1

Either the documented minimum version should be updated, or the code changed to run on older versions.

The Gregorian calendar was introduced in much of Europe in October 1582, with 4th October followed by the 15th October. ICU interprets historical dates based on this transition by default, but Posix and timelib do not.

Using LC_TIME locale if possible will make the function more compatible to the current behaviour.

The Locale class also supports identifiers with dashes and may be more than 5 characters; see https://www.php.net/manual/en/class.locale.php

The buildin strftime currently supports modifiers after the % sign. They are not documented at php.net/manual/en/function.strftime but they work on Linux and I have seen code which is using it.

For example %-d will remove a leading zero if the day of month <10. While %_d will replace the leading zero by a space. I found in a comment that on Windows %#d is doing the same as %-d, so I added it too. This will make it platform-independent ;-)

The class type check will never return false, as DateTime is always an instance of DateTimeInterface. If the passed $timestamp is invalid, then the DateTime constructor will throw an \Exception, therefore the check is not needed.

Currently this library uses EEE and MMM for %a and %b. However I noticed with my own project's test suite that in the German locale that the "stand-alone" formats ccc and LLL more closely mimic what strftime does for %a and %b.

In particular EEE and MMM formats do not always truncate to 3 characters in the German locale (they sometimes generate 2 or 4 characters). They also add a period . after the truncated part which strftime does not do.

Switching to ccc and LLL has no effect on the English and Spanish locales in my test suite.

Looking at what "stand-alone" is for (https://unicode-org.github.io/icu/userguide/format_parse/datetime/#datetime-format-syntax) I think it is more correct to use the stand-alone formats in a strftime polyfill. While using EEE and MMM would potentially improve the output grammar when the format string combines multiple date parts, you'd have to look at the format string as a whole to know if you need to use the stand-alone versions or not. And at least my libc's strftime does not do this.

Hi, it seems that \PHP81_BC\strftime behaves differently from stock strftime for the Italian default year format

<?php
require_once "vendor/autoload.php";

$dt = new \DateTime("2022-01-01 00:00:00");

setlocale(LC_TIME, 'it_IT.utf8');
var_dump(strftime("%x %X", $dt->getTimestamp()));
var_dump(\PHP81_BC\strftime("%x %X", $dt->getTimestamp()));

outputs

string(19) "01/01/2022 00:00:00"
string(17) "01/01/22 00:00:00"