Laravel's timestamp has weird return format

Question

I have a posts Model & Controller and when I try to get all posts, it returns the created_at and updated_at colums as this: "created_at": "2020-05-31T22:04:38.000000Z",

As you can see, there is a weird "T" between the date and time + there's ".000000Z" at the end.

I tried using Carbon::setToStringFormat(); but no luck.

This is my PostsController@index

    {
        Carbon::setToStringFormat(DateTime::ISO8601);
        $posts = Post::with('author:id,name,lastName')->get();
        return response()->json(['posts' => $posts->toArray()],200);
    }

And this problem persists on every single model/migration I have made. Including the users table.

"users": [
    {
      "id": 1,
      "email": "admin@test.com",
      "status": "admin",
      "name": "Administrators",
      "lastName": "Uzvārds",
      "department": "client",
      "phone": "null",
      "created_at": "2020-05-31T22:03:36.000000Z",
      "updated_at": "2020-05-31T22:03:36.000000Z"
    },
    {
      "id": 2,
      "email": "user@test.com",
      "status": "employee",
      "name": "Darbinieks",
      "lastName": "Uzvārds",
      "department": "client",
      "phone": "null",
      "created_at": "2020-05-31T22:03:36.000000Z",
      "updated_at": "2020-05-31T22:03:36.000000Z"
    }
  ]

As you can see, in PHPMyAdmin everything's completely fine:

Answer 1

That’s not “weird”. It’s pretty standard ISO8601 format with a microsecond precision and “Z” (ie. UTC) time zone designation. The ISO8601 format allows a “T” between date and time components, as well as several other variations.

The database display happens to use a different variation. This is OK and expected because the database type is a DATETIME (or similar), so the displayed text is only a given representation. Both representations represent the same date and time^.

This is a good format to transfer information (and is common in JSON serialization), less so to display to a user.

^ Assuming the data in the database is stored from a UTC source, which appears to be the case here. If it’s a local time source there are other complications as the “Z” offset in the JSON would be incorrect/misleading without value adjustments.