use timestamp as primary key

bump.

Using a timestamp as your primary key is a terrible idea. Life is just much easier to use the standard auto incrementing integer as your primary key, especially since there is no guarantee that two timestamps are absolutely unique from one another.

So, I would suggest auto incrementing your id, and then just having an extra "created_at" timestamp column.

Next, you are getting this error because by default, Laravel expects your primary key to be auto incrementing. If for some reason, you are not doing this, you need to put this in your model:

public $incrementing = false;

@jaheller

Time stamps are strings, Laravel expects integers by default.

  protected $primaryKey = 'uid';
    
    protected $casts = [
        'uid' => 'string',
    ];

Obviously the above is for a uid not ID, but concept is the same.

@jekinney

I've edited my model to:

protected $fillable = [
    'id',
    'user_id',
    'message',
];

protected $dates = [
   'id',
];

protected $primaryKey = 'id';

protected $casts = [
    'id' => 'string',
];

public $timestamps = false;

still the same problem.

I agree with @thomaskim you should not use a time stamp as the id. If you remove public $timestamps = false; then you should be able to simply use:

$new_chat = new Chat();
  $new_chat->user_id = 1;
  $new_chat->message = $request->message;
  $new_chat->save();

dd($new_chat->created_at);

Id's are meant to be an unique identifier within the scope of a table and are often used to optimize queries. Time stamps are not guaranteed unique, and are going to be worse for your behind the scenes (inside the database) query optimization. If making this change is creating other errors, I would recommend trying to resolve those versus continuing to use a time stamp for your id.