Hi,

Wouldn't it be nice to have different translations for the Carbon::diffForHumans() method?

setlocale(LC_TIME, 'nl_NL');                     
echo Carbon::now()->subDays(5)->diffForHumans();  // 5 dagen geleden
echo Carbon::now()->addDays(5)->diffForHumans();  // over 5 dagen
setlocale(LC_TIME, '');                           
echo Carbon::now()->subDays(5)->diffForHumans();  // 5 days ago
echo Carbon::now()->addDays(5)->diffForHumans();  // 5 days from now

I don't know how this should be implemented, but I think (for flexibility) you should be able to:

• define the format (sequence/position of each part)
• define the units and other texts

Example configuration:

en.unit.day = "day" en.unit.days = "days" en.unit.week = "week" en.unit.weeks = "weeks" en.pastNow = "ago" en.futureNow = "from now" en.pastValue = "before" en.futureValue = "after" en.format = "{value} {unit} {pastNow}{futureNow}{pastValue}{futureValue}"

nl.unit.day = "dag" nl.unit.days = "dagen" nl.unit.week = "week" nl.unit.weeks = "weken" nl.pastNow = "geleden" nl.futureNow = "over" nl.pastValue = "ervoor" nl.futureValue = "erna" nl.format = "{futureNow} {value} {unit} {pastNow}{pastValue}{futureValue}"

I think this is a good idea, but I have no idea how this should be implemented. Also the variables names as proposed could be better.

Given the amount of PRs and issues, failing travis setups and the last commit being exactly Carbon::now()->subYear(1)… is this project still alive?

@briannesbitt are you planning to continue maintaining Carbon?

Please let us know. This project is a great piece of work and it deserves continuous maintenance. If you are currently not able to maintain the project, maybe there are others willing to help?

If I want to get midnight time for different timezones with initial time I got this problem. For example with timestamp 1485943200 I need to know midnight time for Europe/Moscow and Europe/Samara.

I do this:

$initial = Carbon::createFromTimestamp(1485943200);
$moscow_midnight = $initial->copy()->timezone('Europe/Moscow')->modify('midnight')->getTimestamp();
$samara_midnight = $initial->copy()->timezone('Europe/Samara')->modify('midnight')->getTimestamp();

And got:

$moscow_midnight = 1485907200
$samara_midnight = 1485907200

This is midnight time for GMT 0 for that day not for those timezones.

Creates a CarbonInterval from string in JIRA format (solves #997)

Format:

Suffix | Unit | Example | DateInterval expression ------ | ------- | ------- | ----------------------- y | years | 1y | P1Y M | months | 3M | P3M w | weeks | 2w | P2W d | days | 28d | P28D h | hours | 4h | PT4H m | minutes | 12m | PT12M s | seconds | 59s | PT59S

e. g. 1w 3d 4h 32m 23s is converted to 10 days 4 hours 32 minutes and 23 seconds.

Special cases:

• An empty string will return a zero interval
• Fractions are allowed for weeks, days, hours and minutes and will be converted and rounded to the next smaller value (caution: 0.5w = 4d)

Hi,

since my last update (from 1.22.0 to 1.24.1) I got the following exception:

DateTime::__construct(): Failed to parse time string (2018-03-09 15:58:28.-909518) at position 24 (5): Unexpected character

1.22.0 works perfectly. My timezone is UTC. Could you please help me?

Thanks!

Hello,

I encountered an issue with the following code:

$holidays = ['0' => '2020-12-25', '1' => '2020-12-24']; //etc..
            
return $start_date->diffInDaysFiltered(function (Carbon $d) use ($holidays) {
   return $d->isWeekday() && !array_search($d->format("Y-m-d"), $holidays,true);
}, $end_date);

Carbon version: 2.41.0

PHP version: 7.3.5

I expected to get:

number of diff days between start_date and end_date

But I actually get:

Exception: Unknown getter 'locale'

With version 2.40.1 work!

Hello,

I encountered an issue with the following code:

$now = Carbon::now();

// some milliseconds pass.

echo Carbon::now()->diffInSeconds($now, false);

Carbon version: 1.34.1 PHP version: 7.2.12

I expected to get:

0

But I actually get:

A much higher number (differs depending on how much milliseconds have passed).

I believe this is because https://bugs.php.net/bug.php?id=77007 was merged for 7.2.12 causing differences between these versions. I'm not sure how this should be solved.

The realisation of initial issue #88 is wrong. The problem does not relies to local / not local timezone. Php handles date changes similar for both cases. So in fact changes was made 'fixes' non-local dates but local dates works same as before. And it 'fixes' the problem and not actually fixes it because in fact the PHP handling of DST changing in non-UTC dates is quite right. If developer don't want to adjusting timestamp to DST change he should use UTC timezone.

Hello,

Carbon version: 2.55.0

PHP version: 7.4

In Localization.php line 696:

Class 'Carbon\Translator' not found

Thanks!

|English|sl_SI|comments| |--|--|--| |1 hour|1 uro|This should be "1 ura". If you want to say "1 hour till arrival" then you would use "1 ura", but if you want to say "This took me 1 hour to complete" then "1 uro" is correct. But I think mostly the first example applies so "1 ura" would be better...| |an hour|1 uro|This should be "1 ura". If you want to say "1 hour till arrival" then you would use "1 ura", but if you want to say "This took me 1 hour to complete" then "1 uro" is correct. But I think mostly the first example applies so "1 ura" would be better...| |1 minute|1 minuto|This is the same as with the hours. If you say "Only 1 minute left" then you use "1 minuta", but if you say "We're going in 1 minute" then you use "1 minuto".| |a minute|1 minuto|This is the same as with the hours. If you say "Only 1 minute left" then you use "1 minuta", but if you say "We're going in 1 minute" then you use "1 minuto".| |1 second|1 sekundo|The same as hours and minutes| |a few seconds|1 sekundo|The same as hours and minutes| |2 hours before|pred 2 uri|This should be "2 uri pred" if you want to use it in a sentence like "2 hours before the accident", but if you just say "2 hours before" then you use "pred 2 urama" (but it would be even better to use a word instead of number "pred dvema urama") Because grammar... |2 hours after|čez 2 uri|This should be "2 uri po" if you want to use it in a sentence like "2 hours after the accident", but if you just say "2 hours after" then you use "po 2 urah" (but even prettier would be to use a word "po dveh urah") Because grammar...

Hello,

I encountered an issue with the following code:

echo Carbon::parse('2000-01-15 00:00')->floatDiffInMonths('2000-02-20 00:00');

Carbon version: master of github PHP version: 7.1.3

I expected to get:

any value more than 1

But I actually get:

0.82758620689655

I tried with other dates as well and it seems to have issue. Like:

echo Carbon::parse('2018-12-16 00:00')->floatDiffInMonths('2019-12-15 00:00');

Above code must output a floating value nearing to 12 but instead output shows 10.048387096774

Thanks!

Hi

I can not get custom cascade factors working together with rounding. In the example I want the largest cascade factor to be hours. Without rounding everything works as expected. As soon as as rounding is introduced the custom cascade factors seem to be ignored and I can not get an output with hours larger than 24 anymore (instead they have been converted to days internally). But even totalHours does not work anymore to convert them back to hours afterwards.

It is unexpected that rounding the minutes should have any effect on the hours.

use Carbon\CarbonInterval;

CarbonInterval::setCascadeFactors([
			'millisecond' => [1000, 'microseconds'],
			'second'      => [1000, 'milliseconds'],
			'minute'      => [60, 'seconds'],
			'hour'        => [60, 'minutes'],
		]);

// as expected
echo CarbonInterval::make('43h3m6s')->hours . "\n";
echo CarbonInterval::make('43h3m6s')->cascade()->hours . "\n";
echo CarbonInterval::make('43h3m6s')->cascade()->totalHours . "\n";
echo "\n";

// unexpected
echo CarbonInterval::make('43h3m6s')->roundMinutes()->hours . "\n";
echo CarbonInterval::make('43h3m6s')->roundMinutes()->totalHours . "\n";

Carbon version: 2.64.0 PHP version: 8.1.13

I expected to get:

43
43
43.051666666667

43
43.05

But I actually get:

43
43
43.051666666667

19
19.05

If we drop PHP 8.0, using enums for week days, months and units is an option to be able write chaining in a more natural way, such as:

echo \Carbon\WeekDay::MONDAY->locale('it')->dayName; // lunedì
// equivalent to:
echo \Carbon\CarbonImmutable::parse('Monday')->locale('it')->dayName; // lunedì

echo \Carbon\Month::JANUARY->locale('it')->monthName; // gennaio
// equivalent to:
echo \Carbon\CarbonImmutable::parse('January 1st')->locale('it')->monthName; // gennaio

foreach (\Carbon\Unit::WEEK->stepBy('day') as $day) {
   $days[] = "$day";
}
// equivalent to:
foreach (\Carbon\CarbonInterval::week()->stepBy('day') as $day) {
   $days[] = "$day";
}

Those enums could also be supported in weekday(\Carbon\WeekDay|int $day) or month(\Carbon\Month|int $month)

For now this feature is tentative.

Hello,

I encountered an issue with the following code:

$start = new Carbon("2022-11-11 22:29:50.000000");
$end = $start->copy()->addMonths(3);
$now = $start->copy()->addDay();

echo "diffInMonths\n";
echo $start->diffInMonths($end) . "\n";
echo $now->diffInMonths($end) . "\n";

echo "\nfloatDiffInMonths\n";
echo $start->floatDiffInMonths($end) . "\n";
echo $now->floatDiffInMonths($end) . "\n";

echo "\nfloatDiffInRealMonths\n";
echo $start->floatDiffInRealMonths($end) . "\n";
echo $now->floatDiffInRealMonths($end) . "\n";

Carbon version: 2.x/3.x

PHP version: 7.4.28 / Whatever https://try-carbon.herokuapp.com/ uses

I expected to get:

diffInMonths
3
2

floatDiffInMonths
3
2.9<something>

floatDiffInRealMonths
3
2.9<something>

But I actually get:

diffInMonths
3
2

floatDiffInMonths
3
3.0055439548131

floatDiffInRealMonths
3
3.0055439548131

Thanks!

I have seen and read #2264

The "counting every day by fraction" way from https://github.com/briannesbitt/Carbon/issues/2264#issuecomment-774691425 results in:

>>> CarbonHelper::monthDifferenceDayByDay($start, $end)
=> 3.0595238095238
>>> CarbonHelper::monthDifferenceDayByDay($now, $end)
=> 3.0261904761905

Which is better - at least adding a day makes the difference smaller now, but I'd still expect 3 and < 3 as the results

PHP will fix some DST issues, and behave differently when using add() or modify() which also leads to inconsistency as we use modify() for our add/sub methods.

We also have set of addReal/subReal methods which are quite "good" for hours/minutes/seconds because we use timestamp for "Real" and modify() without "Real" which will convert 25/23 hours on DST days to 24 hours to somehow "ignores" the DST. So "Real" here makes sense. But on days/month/year, they more relate to UTC as 2021-11-07 in New York "really" is a 25-hours day. So adding 24 hours when asking for addRealDay() is no longer the correct word.

For those reasons, we should revise the "Real" behavior and prepare for PHP 8.1.

With the following code:

echo CarbonImmutable::parse('2021-11-07T00:00:00 America/New_York')->addHours(24)->format('j G') . "\n";
echo CarbonImmutable::parse('2021-11-07T00:00:00 America/New_York')->addRealHours(24)->format('j G') . "\n";
echo CarbonImmutable::parse('2021-11-07T00:00:00 America/New_York')->modify('24 hours')->format('j G') . "\n";
echo CarbonImmutable::parse('2021-11-07T00:00:00 America/New_York')->add(CarbonInterval::hours(24))->format('j G') . "\n";
echo "\n";
echo CarbonImmutable::parse('2021-11-07T00:00:00 America/New_York')->addDay()->format('j G') . "\n";
echo CarbonImmutable::parse('2021-11-07T00:00:00 America/New_York')->addRealDay()->format('j G') . "\n";
echo CarbonImmutable::parse('2021-11-07T00:00:00 America/New_York')->modify('1 day')->format('j G') . "\n";
echo CarbonImmutable::parse('2021-11-07T00:00:00 America/New_York')->add(CarbonInterval::day())->format('j G') . "\n";
echo "\n\n";
echo CarbonImmutable::parse('2021-03-14T00:00:00 America/New_York')->addHours(24)->format('j G') . "\n";
echo CarbonImmutable::parse('2021-03-14T00:00:00 America/New_York')->addRealHours(24)->format('j G') . "\n";
echo CarbonImmutable::parse('2021-03-14T00:00:00 America/New_York')->modify('24 hours')->format('j G') . "\n";
echo CarbonImmutable::parse('2021-03-14T00:00:00 America/New_York')->add(CarbonInterval::hours(24))->format('j G') . "\n";
echo "\n";
echo CarbonImmutable::parse('2021-03-14T00:00:00 America/New_York')->addDay()->format('j G') . "\n";
echo CarbonImmutable::parse('2021-03-14T00:00:00 America/New_York')->addRealDay()->format('j G') . "\n";
echo CarbonImmutable::parse('2021-03-14T00:00:00 America/New_York')->modify('1 day')->format('j G') . "\n";
echo CarbonImmutable::parse('2021-03-14T00:00:00 America/New_York')->add(CarbonInterval::day())->format('j G') . "\n";

Note due to DST in New York: There is 25 hours between 2021-11-07 midnight and 2021-11-08 midnight There is 23 hours between 2021-03-14 midnight and 2021-03-15 midnight

Carbon version: 2.48.1

Current result on PHP 8.0.0:

8 0
7 23
8 0
7 23

8 0
7 23
8 0
8 0


15 0
15 1
15 0
15 0

15 0
15 1
15 0
15 0

Current result on PHP 8.1.0-dev (WIP master branch):

8 0
7 23
8 0
7 23

8 0
7 23
8 0
8 0


15 0
15 1
15 0
15 1

15 0
15 1
15 0
15 0

Difference from 8.0 to 8.1 is:

CarbonImmutable::parse('2021-03-14T00:00:00 America/New_York')->add(CarbonInterval::hours(24))->format('j G') 

8.0: 15 0 8.1: 15 1 This behavior aligns what happen on March DST change with what happen on November DST change.

For the record:

• Lines with G (hour) = 0 match the proper expectation for adding 1 day from New York point of view. Or adding 24 to the hour property of the date with overflow (that's kind of real-time-agnostic point of view where you don't consider "24 hours" as a duration but as an increment of the hour unit)
• Lines with G (hour) = 1 or 23 match the proper expectation for adding 24 hours from New York point of view (such as concretely waiting 24 hours = 24 * 3600 seconds).