In our RESTful api we use Carbon (which is great b.t.w.) to parse dates. In some cases we get this error:
exception 'Exception' with message 'DateTime::__construct(): Failed to parse time string (Mon Jun 27 2016 00:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)) at position 41 (e): Double timezone specification' in...
This is from one of our German clients and we've solved it by converting the date object in frontend code to a valid string, but it seems unnecessary to me.
Since i couldn't find anything online i hoped you could help me out.
...
lucas@air:~/Gits/briannesbitt/carbon | master :
> psysh
Psy Shell v0.7.2 (PHP 7.0.8 — cli) by Justin Hileman
>>> $date = new \Datetime('Mon Jun 27 2016 00:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)');
Exception with message 'DateTime::__construct(): Failed to parse time string (Mon Jun 27 2016 00:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)) at position 41 (e): Double timezone specification'
>>> $date = new \Datetime('Mon Jun 27 2016 00:00:00 GMT+0200');
=> DateTime {#179
+"date": "2016-06-27 00:00:00.000000",
+"timezone_type": 1,
+"timezone": "+02:00",
}
>>>
Then just parse Mon Jun 27 2016 00:00:00 GMT+0200 without (Mitteleuropäische Sommerzeit)
Sure that's an option. Reason why I posted the issue is that one might ( I did) expect Carbon to handle these dateobjects since that is the reason to use Carbon in the first place, not to have to check each datestring and then handing it over to Carbon. The particular issue is solved for our app, but I thought it would be nice to share the issue as a point of improvement.
Can this be closed @arjenduinhouwer ?
Just ran into this issue myself with a date coming in from an Angular app. Would be good if Carbon could handle this gracefully.
Feel free to use any TZ listed on PHP.net website
@arjenduinhouwer hi I am newie on this and I have the same issue as you I don't know how to fix it. it only happens on windows, what you migth suggest for me how I might handle this issue?
Have you guys commited any changes related to this issue?
@lesliek07 same here, the issue happens only on windows machines
same here
DateTime::__construct(): Failed to parse time string (Fri Sep 20 2019 00:00:00 GMT+0700 (Indochina Time)) at position 41 (i): Double timezone specification
(Indochina Time) is not a valid string for the DateTime constructor. It's a native limitation of PHP, not a Carbon issue.
Carbon::parse('Fri Sep 20 2019 00:00:00 GMT+0700') works well.
im experiencing this as well. am i wrong for assuming that carbon should be able to handle a "new Date()" passed in from javascript?
new Date() is an object from JS land, there is absolutely no way to pass it as an instance to any kind of PHP script. It's not a Carbon issue. It's about communication between PHP and JS. To exchange data across different languages, you need to convert it in a flat (scalar) representation (or V8Js extension but the principle is the same under the hood). The standard is to use JSON. So:
JS Date to JSON
(new Date()).toJSON()
Carbon (and even pure DateTime) in PHP will perfectly understand this representation.
PHP Carbon instance to JSON
(new Carbon())->toJSON()
It gives the exact same format and JS will perfectly understand this representation.
What you see when you cast a new Date() as a string from the JS side is NOT a normalized string aimed to be passed to an other system/language or a server. It's a human-friendly output aimed to be displayed on screen to your users or help you to debug in your console, etc.
So it's normal this string can contain additional non standard data coming from browser side (OS, browser...), as you can see "Mitteleuropäische Sommerzeit" is in Deutsch and can actually be in any language in the world. PHP does not handle every names of every timezones in every languages, sorry. But you can still trim those data and use this input as Carbon:
$dateString = 'Mon Jun 27 2016 00:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)';
$dateString = preg_replace('/\(.*$/', '', $dateString);
echo Carbon::parse($dateString);
Still it's not the correct way to exchange date between JS and PHP. JSON is. And browser timezone should be sent separately using:
Intl.DateTimeFormat().resolvedOptions().timeZone
which is more precise, in ISO format and can be sent only once as it does not change.
Most helpful comment
Sure that's an option. Reason why I posted the issue is that one might ( I did) expect Carbon to handle these dateobjects since that is the reason to use Carbon in the first place, not to have to check each datestring and then handing it over to Carbon. The particular issue is solved for our app, but I thought it would be nice to share the issue as a point of improvement.