[Question] Why is there no microseconds in date_create_from_format ?

[zeriyoshi]

Description

Hello,

It appears that date_create_from_format uses the current time for date and time components, but deliberately excludes microseconds.

$ php -r 'echo date_create_from_format("md", "0909")->format("Y-m-d H:i:s.u"), \PHP_EOL;'
2024-09-09 10:05:01.000000

Looking at the source code, it seems that there's a condition that specifically avoids handling microseconds. Does anyone know the reason for this? (Is it to prevent unintentionally creating instances that are not equal?)

If there isn't a strong reason for this behavior, I think it might be worth considering including microseconds in PHP 8.5. (Would this require an RFC?)

[iluuu1994]

/cc @derickr

[gzhegow1991]

Nope, you just created date using 09 month 09 day, why resulting object should get CURRENT microseconds?

You have to call

<?php
var_dump(date_create_from_format('md.u', '0909.123456'));

// object(DateTime)#1 (3) {
//   ["date"]=>
//   string(26) "2024-09-09 00:00:00.123456"
//   ["timezone_type"]=>
//   int(3)
//   ["timezone"]=>
//   string(3) "UTC"
// }

Actually only thing that is used from CURRENT scope - is Timezone. Only just because timezone have to be, and btw it configured via date_default_timezone_set() globally

Maybe you want some method like "now_create_from_format()" but it would be kinda subjective tool.

[zeriyoshi]

@6562680
I apologize for the poor example earlier. What I meant to ask was why default values are not used for hours, minutes, and seconds, while they are for other components.

In the following code, unspecified values for Ymd are filled with the current date. However, for some reason, His doesn't follow this pattern and is filled with zeros instead.

Moreover, unlike other functions that handle current date and time, this function doesn't deal with microseconds at all unless explicitly specified. This behavior seems a bit unnatural.

php > date_default_timezone_set("Asia/Tokyo");
php > date_create_from_format("Y", 1994);
php > date_default_timezone_set("Asia/Tokyo");
php > var_dump(date_create_from_format("Y", 1994));
object(DateTime)#1 (3) {
  ["date"]=>
  string(26) "1994-09-10 09:30:06.000000" // 1994-NOW-NOW NOW:NOW:NOW.000000
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(10) "Asia/Tokyo"
}
php > var_dump(date_create_from_format("m", 10));
object(DateTime)#1 (3) {
  ["date"]=>
  string(26) "2024-10-10 09:30:16.000000" // NOW-10-NOW NOW:NOW:NOW.000000
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(10) "Asia/Tokyo"
}
php > var_dump(date_create_from_format("d", 26));
object(DateTime)#1 (3) {
  ["date"]=>
  string(26) "2024-09-26 09:30:20.000000" // NOW-NOW-26 NOW:NOW:NOW.000000
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(10) "Asia/Tokyo"
}
php > var_dump(date_create_from_format("H", 15));
object(DateTime)#1 (3) {
  ["date"]=>
  string(26) "2024-09-10 15:00:00.000000" // NOW-NOW-NOW 15:00:00.000000
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(10) "Asia/Tokyo"
}

I was wondering if there's a reason for this behavior.

[zeriyoshi]

Off-topic, but I'm currently creating a PHP Extension to change the current time for maintaining old projects at work, and I noticed this specification:

https://github.com/colopl/php-colopl_timeshifter/blob/main/ext/hook.c#L107

When a DateTime object is created, there's no internal way to determine whether it was created from relative time or absolute time. Therefore, a 1 microsecond wait is inserted to detect this. Since create_from_format doesn't set microseconds, a wait of at least 1 second is necessary to determine whether it's an absolute or relative value.

[gzhegow1991]

Agree with 1. Guess its because there's no "zero year/month/day" instead of hour/minute/second/microsecond. So, the date and timezone used from Current, time - used as passed... Strange for the first look, but... is another way possible?

About 2, "take the direct moment" is the wrong way even in microelectronics. Computers work as a pulse generator, and the processor does some work on each pulse. The logic SHOULD NOT require registering the time of a particular pulse, because the machine is not synchronous.

Create a date object that represents time roughly enough for 95% of tasks. For relative dates - create two dates, then subtract. With some approximation, the answer is correct. It's just that if you need to compare 2 tensor readings with exact subtraction with high accuracy, maybe... maybe you need an additional tool for this... And also, you have tensors for extra accuracy.

By the way, time() and microtime(), I think, spent as little time as possible.

[derickr]

@zeriyoshi I believe we did it this way because of BC reasons, when we introduced microsecond support.

[zeriyoshi]

@derickr
Thank you for checking! I see, that's interesting!

This behavior lacks consistency, and it might be better to make some changes to it in the future.
It's particularly tricky that microseconds are only applied when specifying just the timezone.

https://3v4l.org/tePJL

However, DateTime is already quite complex, and there might not be many people who would appreciate further changes...

[zeriyoshi]

For now, I'll close this issue as my question has been resolved.
When PHP-8.5 comes up in discussions, I'll notify the mailing list if I remember :)