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?

https://github.com/alphp/strftime/blob/master/src/php-8.1-strftime.php#L43C5-L43C76

When passing Carbon aka DateTime object to this strftime which has it's own timezone, it will always be formatted in the "default" server timezone?

Why is this overridden?
Normally when it would have initiated from an "integer" it would have already have "default" timezone?!

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"

The code (new IntlDateFormatter('C'))->format(new DateTime()) generates a fatal error on the latest PHP 8.x releases, see a reproduction case here and the exception below:

PHP Fatal error: Uncaught Error: Found unconstructed IntlDateFormatter in /var/www/html/vendor/php81_bc/strftime/src/php-8.1-strftime.php:100

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.

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.

Hi!

I believe that this code:

 $timestamp = is_int($timestamp) ? '@' . $timestamp : (string) $timestamp;

should better be:

$timestamp = is_numeric($timestamp) ? '@' . $timestamp : (string) $timestamp;

because there might be places where a "string" like "168023423" is passed (typed as a string), but DateTime constructor will then complain if it's passed as a string. is_numeric() would be the better choice to see if a variable only contains numbers...?

Regards,
Garvin

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.

Try the following test script. (You may have to generate the fa_IR locale on your system first.)

<?php

setlocale(LC_ALL, 'fa_IR') || die("Could not set locale!\n");
require_once('autoload.php');

echo PHP81_BC\strftime('%b', time());

You will get a fatal error message:

PHP Fatal error:  Uncaught Error: Call to undefined method IntlCalendar::setGregorianChange() in /path/to/test.php:5
Stack trace:
#0 {main}
  thrown in /path/to/test.php on line 5

This is because IntlGregorianCalendar::createInstance() will not return an IntlGregorianCalendar when the locale is set to something non-Gregorian. (Note that the error message says it's an IntlCalendar.)

Pull request: #16

(Source: https://forum.pkp.sfu.ca/t/submission-files-is-not-showing-in-ojs-3-3-0-11/83976/10)

Hey, great work! But I still miss %i for 24-hour format. So you could add this line after line 149:
'%i' => 'G',