Laravel expects timestamp columns to be named created_at and updated_at. When you’re working with a database you can’t change — a legacy schema, a multi-app database, a third-party system — those column names might be different. Two constants in your model fix this without any database changes.
:::note[TL;DR]
- Override
const CREATED_ATandconst UPDATED_ATto rename timestamp columns in the model - Set
public $timestamps = false;to disable timestamp management entirely - Use
protected $dateFormat = 'U';to store Unix timestamps instead of datetime strings - These changes are model-level only — they don’t alter your database schema
- Works in Laravel 10, 11, and 12 :::
How do I rename the created_at and updated_at columns?
Scenario: You’re integrating a legacy database that uses
date_createdanddate_modifiedinstead ofcreated_atandupdated_at. Other apps depend on the schema — you can’t rename the columns. Two constants in the Eloquent model map Laravel’s expectations to your actual column names.
Define CREATED_AT and UPDATED_AT as string constants in your model class. Laravel reads these constants instead of the defaults.
<?php
namespace App\Models;
use Illuminate\Database\Eloquent\Model;
class LegacyProduct extends Model
{
/**
* The column that stores the creation time.
*/
const CREATED_AT = 'date_created';
/**
* The column that stores the last update time.
*/
const UPDATED_AT = 'date_modified';
}After this, LegacyProduct::create([...]) writes to date_created and date_modified. LegacyProduct::find(1)->update([...]) updates date_modified. Everything else in Eloquent — orderBy('date_modified', 'desc'), $model->updated_at accessor via Carbon — works as expected, but against your renamed columns.
How do I rename the soft delete column?
If your model uses SoftDeletes, override DELETED_AT the same way. This maps the soft delete timestamp to any column name you need.
<?php
namespace App\Models;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\SoftDeletes;
class LegacyRecord extends Model
{
use SoftDeletes;
const CREATED_AT = 'date_created';
const UPDATED_AT = 'date_modified';
const DELETED_AT = 'date_removed';
}Soft deletes now write to date_removed instead of deleted_at. Queries that use withTrashed() and onlyTrashed() still work correctly.
How do I disable timestamps entirely?
Set public $timestamps = false; as a class property. Eloquent won’t attempt to read or write any timestamp columns for this model.
<?php
namespace App\Models;
use Illuminate\Database\Eloquent\Model;
class ClickEvent extends Model
{
public $timestamps = false;
}This is common for:
- Lookup/reference tables that never change
- Pivot tables (though Laravel’s
withTimestamps()handles these) - Log tables where timestamps are managed externally
- Tables imported from legacy systems that have no timestamp columns at all
:::warning
If you disable timestamps and your table actually has created_at / updated_at columns, those columns won’t be filled on insert. You’ll end up with NULL values unless you set them manually. Make sure your table schema matches the model’s timestamp setting.
:::
How do I use a custom date format for timestamps?
Set protected $dateFormat to any format string PHP’s date() function accepts. The format applies to how Eloquent reads and writes the timestamp columns.
To store Unix timestamps (integers) instead of datetime strings:
protected $dateFormat = 'U';This stores timestamps as integers like 1743024000 rather than 2025-12-25 14:30:00. Useful when you need fast integer comparisons or when the legacy schema stores times this way.
You can also use a custom datetime string format:
// Stores as: 25/12/2025 14:30:00
protected $dateFormat = 'd/m/Y H:i:s';:::warning
Custom $dateFormat affects how ALL date columns are read and written on the model, not just timestamps. If your model has other date/datetime columns in $casts, they’ll also use this format. Check for unintended side effects when using non-standard formats.
:::
What does this look like in a migration?
The constants control the Eloquent model layer only. Your migration still needs to match. Here’s an anonymous migration (required in Laravel 10+) creating a table with custom column names:
<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
return new class extends Migration
{
public function up(): void
{
Schema::create('legacy_products', function (Blueprint $table) {
$table->id();
$table->string('name');
// Custom timestamp columns to match the model constants
$table->timestamp('date_created')->nullable();
$table->timestamp('date_modified')->nullable();
});
}
public function down(): void
{
Schema::dropIfExists('legacy_products');
}
};The column names in the migration must match what you defined in the model constants — that’s the only place the mapping happens.
Summary
- Override
CREATED_ATandUPDATED_ATconstants in your model to rename timestamp columns - Override
DELETED_ATfor soft-delete column renaming - Set
public $timestamps = false;to stop Eloquent from managing timestamps at all - Use
$dateFormat = 'U'to store Unix integer timestamps instead of datetime strings - All of this is model-layer only — no database schema changes required
FAQ
Do I need to change my migrations if I rename the constants? Yes. The constants tell Eloquent which column names to use. Your actual database column names must match whatever you set in the constants. Eloquent doesn’t rename columns for you.
Can I override timestamps on a per-model basis without affecting other models?
Yes. Constants and properties defined on a model class are scoped to that model. Other models keep the created_at / updated_at defaults unless you override them too.
What happens to $model->created_at if I rename the column to date_created?
The created_at accessor on the model will return null unless you also add protected $appends logic. Access the value using the actual column name: $model->date_created. Or define a getCreatedAtAttribute() accessor if you need the ->created_at syntax to keep working.
Is there a way to rename columns in the migration itself to match Laravel’s defaults instead?
Yes. If you’re creating a new database, use Laravel’s default names. The constants approach is specifically for when you can’t change the schema. If you have control over the schema design, use created_at and updated_at — it keeps your codebase simpler.
Does this work in Laravel 10, 11, and 12?
Yes. The CREATED_AT, UPDATED_AT, and DELETED_AT constant overrides have been stable for many major versions, including 10, 11, and 12.
What to Read Next
- Update a Laravel Record Without Touching Timestamps — save without changing
updated_at - Laravel firstOrCreate(): Find or Create a Record — Eloquent shortcut for find-or-insert operations
- Get Last 30 Days Records in Laravel — date-range filtering with Eloquent
