Carbon createFromFormat 意外结果

Question

::createFromFormat() 结果提前一个月：

var_dump($_GET['archive']);
var_dump(Carbon::createFromFormat('m/Y', $_GET['archive']));

结果：

string '11/2015' (length=7)
object(Carbon\Carbon)[160]
  public 'date' => string '2015-12-01 10:38:41.000000' (length=26)
  public 'timezone_type' => int 3
  public 'timezone' => string 'Europe/London' (length=13)

Answer 1

如果没有提供，Carbon 似乎使用当前日期。因此

var_dump(Carbon::createFromFormat('m/Y', '10/2015'));
var_dump(Carbon::createFromFormat('m/Y', '11/2015'));

结果例如7 月 31 日在

object(Carbon\Carbon)[156]
  public 'date' => string '2015-10-31 11:03:10.000000' (length=26)
  public 'timezone_type' => int 3
  public 'timezone' => string 'Europe/London' (length=13)
object(Carbon\Carbon)[138]
  public 'date' => string '2015-12-01 11:03:10.000000' (length=26)
  public 'timezone_type' => int 3
  public 'timezone' => string 'Europe/London' (length=13)

因为 10 月有 31 日，但 "November 31st is actually December 1st"。

Answer 2

看来你运气不好，因为你是在这个月的 31 号测试的。

但是，这（显然）是一个记录在案的功能。参见：http://php.net/manual/en/datetime.createfromformat.php

如果您设置格式掩码 "correctly"，它会如您所愿地工作。

$x = Carbon::createFromFormat   ('m/Y', '04/2009');
$y = DateTime::createFromFormat ('m/Y|', '04/2009');
dd ($x, $y);

为了避免歧义，Carbon 函数只是 PHP 的底层 DateTime 函数的包装；我只是想证明这不是让我们头疼的 Carbon 功能。

如果您在当月的 31 日测试，上面的 $x 将被读作 31 April 2009，将显示为 5 月 1 日。

虽然掩码中有管道符号，但所有未声明的时间变量（H、i、s）都设置为零，日期变量（d, m) 设置为 1，因此 $y 将始终按您期望的方式响应，而不管星期几。

对于我在本月第 4 天晚上 17:46 进行的测试，上面的代码产生以下结果：

Carbon @1233769590 {#219 ▼
    date: 2009-02-04 17:46:30.0 Europe/London (+00:00)
}

DateTime @1233446400 {#217 ▼
    date: 2009-02-01 00:00:00.0 Europe/London (+00:00)
}

在我看来，date/time 函数的实现非常奇怪。您想要使用此函数的唯一真实情况是，如果您正在从外部源（例如 XML "date" 字段）读取数据。

地球上哪个程序员会希望他们的程序假设传入数据的缺失时间（或在您的情况下为天）组件应该从运行时执行时间中获取？这绝对是疯狂的疯子。

Carbon createFromFormat 意外结果

Carbon createFromFormat unexpected result

php

php-carbon