Introduction

In Django, the creation timestamp belongs on the model, not in the form. A ModelForm is only a mechanism for editing model data, so the clean way to assign a creation date automatically is to define it on the model with auto_now_add=True and keep that field out of the form entirely.

Put the Timestamp on the Model

Django already has a built-in pattern for creation timestamps:

1from django.db import models
2
3class Article(models.Model):
4    title = models.CharField(max_length=200)
5    body = models.TextField()
6    created_at = models.DateTimeField(auto_now_add=True)
7    updated_at = models.DateTimeField(auto_now=True)

auto_now_add=True means Django sets created_at when the object is first inserted. auto_now=True updates a second field whenever the object is saved again. For most applications, that is the correct level to manage time metadata because it stays tied to the data model regardless of which form, admin page, or import path created the record.

Keep the Field Out of the ModelForm

Since Django fills the creation timestamp automatically, the form should not ask the user for it.

1from django import forms
2from .models import Article
3
4class ArticleForm(forms.ModelForm):
5    class Meta:
6        model = Article
7        fields = ["title", "body"]

Now the user submits only the editable fields, and when form.save() runs, Django writes the model instance and stamps the creation time for you.

form = ArticleForm(request.POST)
if form.is_valid():
    article = form.save()

This keeps form code simple and avoids the common mistake of duplicating timestamp logic in the view layer.

When You Need Custom Timestamp Logic

Sometimes auto_now_add=True is not flexible enough. Maybe you want to set the creation time only under certain conditions, copy it from imported data, or allow privileged users to override it. In that case, define a normal DateTimeField and set it yourself.

1from django.utils import timezone
2
3class Article(models.Model):
4    title = models.CharField(max_length=200)
5    body = models.TextField()
6    created_at = models.DateTimeField(default=timezone.now)

Using default=timezone.now still gives an automatic value, but it is easier to override in tests, migrations, or custom import workflows.

Time Zones Matter

If your project uses USE_TZ = True, Django stores timezone-aware datetimes. That is usually what you want. It keeps timestamps consistent across servers, users, and daylight-saving transitions.

The important design point is that time handling should stay centralized. Once multiple forms or views start writing timestamp values by hand, projects become inconsistent very quickly.

Another practical benefit of model-level timestamps is that every creation path behaves the same way. Admin actions, management commands, data imports, test fixtures, and regular form submissions all produce consistent metadata because the rule lives with the model instead of being copied into several views.

That consistency becomes especially valuable later, when reporting or audit features depend on trustworthy creation times. A field populated by the model is much less likely to drift than one populated opportunistically in whichever form handler happened to create the object.

Common Pitfalls

• Putting the creation date field on the form when users should not edit it.
• Setting timestamps in the view when the model can manage them directly.
• Confusing auto_now_add with auto_now.
• Using naive datetimes in projects that expect timezone-aware values.
• Overriding model save() for simple timestamp behavior that built-in field options already cover.

Summary

• Put automatic creation timestamps on the Django model, not in the form.
• Use auto_now_add=True for standard created-at behavior.
• Exclude the timestamp field from the ModelForm fields list.
• Use default=timezone.now only when you need more control.
• Keep timestamp logic centralized so every code path behaves consistently.