Added Namespace and lost all the PHP OOPs Classes

[Dormilich]

If you leave that to PHP’s date extension (as shown in post #19) you don’t need to remember when the DST is. And it’s much less code.

[John_Betong]

@Dormilich

If you leave that to PHP’s date extension (as shown in post #19) you don’t need to remember when the DST is. And it’s much less code.

I did try your script with the JSON “time” and it failed with an obscure error message instead of returning an object:

$json_datetime = '2018-11-02T13:15:37.346992742Z';
$datetime      = new DateTimeImmutable($json_datetime);
..
..

The prettified error message returned:

Fatal error: Uncaught Exception:
DateTimeImmutable::__construct():
Failed to parse time string (2018-11-02T13:15:37.346992742Z) at position 0 (2):
The timezone could not be found in the database in /…/…/incs/latest.php:67

Stack trace: #0 /…/…/…/incs/latest.php(67):
DateTimeImmutable->__construct(‘2018-11-02T13:1…’)
#1 {main} thrown in /…/…/…/incs/latest.php on line 67

I did not understand the error message, had lots of other niggly problems to solve because I moved the script to another URL so continued with the script that worked.

I have since solved most of the other niggly problems, returned, tested and discovered $json_datetime; parameter must conform to a certain structure. The supplied JSON parameter had an extra character preceding the trailing Z. Removing the extra character and your script worked fine.

Many thanks

[Dormilich]

@John_Betong

I did not understand the error message

It basically says that the default timezone your PHP installation uses is garbage.

• check what timezone is set in php.ini
• if there is none, set either your local timezone or UTC
• if there is something set that doesn’t make sense, correct

[John_Betong]

@Dormilich

It basically says that the default timezone your PHP installation uses is garbage.

Unfortunately the problem was inconsistent and not easy to pinpoint.

The following online sample of ten test results show how some Sensor Device_id intermittently return the correct results:

FAIL: Device_id = 3 --- TIME = 2018-11-10T16:00:37.693331725Z
FAIL: Device_id = 1 --- TIME = 2018-11-10T16:06:14.769221807Z
FAIL: Device_id = 1 --- TIME = 2018-11-10T16:21:43.884132598Z
FAIL: Device_id = 3 --- TIME = 2018-11-10T16:22:59.713155252Z
FAIL: Device_id = 2 --- TIME = 2018-11-10T16:26:17.988400055Z
FAIL: Device_id = 1 --- TIME = 2018-11-10T16:29:28.364164087Z
FAIL: Device_id = 1 --- TIME = 2018-11-10T16:37:12.865353714Z
FAIL: Device_id = 3 --- TIME = 2018-11-10T16:42:52.600596748Z
FAIL: Device_id = 1 --- TIME = 2018-11-10T16:44:57.547324099Z
FAIL: Device_id = 2 --- TIME = 2018-11-10T16:46:41.122911915Z

PASS: Device_id = 1 --- TIME = 2018-10-15T19:51:59.11664968Z
PASS: Device_id = 1 --- TIME = 2018-10-15T20:04:21.82335334Z
PASS: Device_id = 1 --- TIME = 2018-10-15T20:19:12.78846381Z
PASS: Device_id = 2 --- TIME = 2018-10-15T20:20:29.09019818Z
PASS: Device_id = 2 --- TIME = 2018-10-15T20:27:55.28019383Z
PASS: Device_id = 1 --- TIME = 2018-10-15T21:16:08.66904935Z
PASS: Device_id = 2 --- TIME = 2018-10-15T21:59:39.71886252Z
PASS: Device_id = 2 --- TIME = 2018-10-15T22:14:32.27015227Z
PASS: Device_id = 2 --- TIME = 2018-10-15T22:19:29.90908701Z
PASS: Device_id = 1 --- TIME = 2018-10-15T22:30:24.01548308Z

$iPass ==> 1896
$iFail ==> 17253
$Total ==> 19149

I did find this post which I think maybe the problem.

https://secure.php.net/manual/en/datetime.createfromformat.php

Fabian ¶1 year ago
Parsing RFC3339 strings can be very tricky when their are microseconds in the date string.

Since PHP 7 there is the undocumented constant DateTime::RFC3339_EXTENDED (value: Y-m-d\TH:i:s.vP), which can be used to output an RFC3339 string with microseconds:

<?php $d = new DateTime(); var_dump($d->format(DateTime::RFC3339_EXTENDED)); // 2017-07-25T13:47:12.000+00:00 ?>

But the same constant can’t be used for parsing an RFC3339 string with microseconds, instead do:

<?php
$date = DateTime::createFromFormat("Y-m-d\TH:i:s.uP", "2017-07-25T15:25:16.123456+02:00")
?>

But “u” can only parse microseconds up to 6 digits, but some language (like Go) return more than 6 digits for the microseconds, e.g.: “2017-07-25T15:50:42.456430712+02:00” (when turning time.Time to JSON with json.Marshal()). Currently there is no other solution than using a separate parsing library to get correct dates.

Note: the difference between “v” and “u” is just 3 digits vs. 6 digits.

The Workaround:

Truncate the trailing milliseconds because they are not required:

  // $row->time = '2018-10-27T08:36:25.356781773Z';	 

  $json_datetime = strstr($row->time, '.', true); // remove milliseconds
  
  // Result:
  /*
	$row->time ==> 2018-10-27T08:36:25.356781773Z

	$json_datetime ==> 2018-10-27T08:36:25

    DateTimeImmutable Object
    (
        [date] => 2018-10-27 08:36:25.000000
        [timezone_type] => 3
        [timezone] => Asia/Bangkok
    )
  */