When I am looking to create some timestamp fields (or other date/time style fields), what is the best way to name them? Should I just put record_timestamp?


13 Answers 13


You should describe the purpose of the column and not necessarily the data type. You can include date/time/timestamp in the name, but you should also include the meaning. For example

  • CreationDate
  • StartDate
  • StatusTime
  • Accessed
  • Updated

Adding Date/Time/Timestamp and such at the end is particularly useful when the abscence of the addition would conflict with another column. For example, a table may need both a Status and a StatusTime.

  • 3
    Just to add my two cents. I worked with many legacy MRP systems and found CreatedOnUtc and UpdatedOnUtc used often. Commented Sep 20, 2016 at 1:40
  • 11
    I think "Accessed" and "Updated" can be ambiguous, since it can also imply boolean (at least in Ruby world) Commented Jun 2, 2017 at 13:26
  • 2
    @GeovaniMartinez that can be confusing, as a lot of SQL databases, PostgreSQL included, store at UTC and read in client's timezone. Commented Jun 2, 2017 at 14:11
  • And if the time unit is supposed to be UTC vs System Local then specify _UTC in the column name. Thank you from all of us who must maintain the code later. Commented Jan 30, 2018 at 17:55
  • Accessed and Updated could be ambiguous with WHO accessed or updated, which is a fairly common thing to track Commented Mar 20, 2018 at 15:56

How about xyz_at for a timestamp and xyz_on for a date field - eg start_at or start_on?

Normally I'd avoid including the data type in the field name - much better if you can infer what you need to know about the type from the name of any field (a field called description is unlikely to be an integer) - but being able to tell the difference between a timestamp and a date is often helpful.


I use:

  • created_at
  • updated_at
  • 2
    "at" can imply location too. What about "when" instead of "at"?
    – Sepster
    Commented Oct 22, 2013 at 1:12
  • 4
    "at" or "as at" is used frequently in legal and financial documents to refer to when something happened. english.stackexchange.com/questions/112770/… Commented Dec 19, 2013 at 19:05
  • 3
    It can still be ambiguous. What if you need to know the time and location at which is was updated? updated_at could be either. But I think the answer is, as always with naming, use the most concise name that removes all realistic ambiguity. I.e. if in a particular context there is potential for a certain confusion, eliminate it, but don't use names that are more verbose than is required for that
    – nafg
    Commented Mar 17, 2017 at 0:22
  • 7
    how about "on". Although it implies a date more than a time, it's still pretty obvious Commented Mar 20, 2018 at 15:57
  • 1
    Update location is much less frequently stored in software than when something was updated, so it doesn't make sense to give it too much weight. Because it's used much less often, then something more verbose like update_location, update_location_id would be acceptable.
    – coatesap
    Commented Aug 19, 2021 at 12:22

I found that using column names such as create_time, update_time and expire_time leads to better readability when it comes to method naming and specs (RSpec).


I looked at your profile and it says you work with SQL Server and in SQL Server TIMESTAMP data type has nothing to do with date or time and its used to kind of version stamping the rows. This is very useful in identifying which rows have been modified from a given point of time.

If you use TIMESTAMP then you don't have to specify a column name and SQL Server will create a column "TimeStamp" for you. But it is recommended to use "ROWVERSION" data type and in this case you have to specify the column name.

What's the best name for a column like this? It depends, and I would use something like VersionStamp, RV etc... What I consider important is NOT how you name it but are you using that consistently across the board.


Ref: http://msdn.microsoft.com/en-us/library/ms182776(v=sql.90).aspx



There is no exact right way to do it, only important thing is to be consistent across your code base and databases so developers are not confused.

Exact naming depends on the language conventions but I would choose one of the following below:

Python, Java, ORACLE/Postgresql

created_at, createdAt, CREATED_AT // Time when the record was created
updated_at, updatedAt, UPDATED_AT // Time when the record was last modified
started_at, startedAt, STARTED_AT // Some other record time


create_time, createTime, CREATE_TIME
update_time, updateTime, UPDATE_TIME
start_time, startTime, START_TIME

Pretty much all fields are stored as timestamp, there will some fields required as date but usually they are more related to the business domain and could be named as per coming request

  • birthday
  • realase_date
  • business_day

All timestamp fields to be stored in UTC.


I prefer using conventions that already exist.

Unix and programming languages have a widely accepted convention of mtime for Modification Time

For creation time,

  • BSD and Windows use birthtime
  • Windows also uses Creation Time
  • xstat uses btime
  • ext4 uses crtime
  • JFS and btrfs use otime (don't ask, guessing "origination").

So for me, I pick mtime, and crtime for meta data.

For user supplied data, I go with what the field represents. If it's a birthday, I just say user_birthday.

As far as precision, for some it seems to hang them up on too much precision. You can store your birthdate as a timestamp (after all you were technically birthed at a time of day), but the SQL spec has casts from higher-precision to lower precision so if you're using a decent database this shouldn't be an issue. In your app itself, you can always truncate when needed. That is to say, I would never go birthday_date.

  • 2
    This convention is terrible. You cannot figure out on your own what such variables mean. You need to know what the "m" or "cr" stand for. I really hate pretty much all unix conventions and magic abbreviations for absolutely everything and anything: etc, usr, cpy, md, rd, mtime, btime... gosh who came up with it? :-| Commented Jun 22, 2023 at 12:26
  • occurrence time Commented Mar 7 at 15:40

As suggest by @Evan Carroll, go with the existing standards unless you have strong reason to break the pattern.

If this is something new then you can follow any answer which best suits you.

I use *_on and *_by because it helps me to keep it consistent for when and who of the row:

- created_on & created_by
- updated_on & updated_by
- deleted_on & deleted_by -- soft delete
- approved_on & approved_by

I prefer to use a prefix of DT for date stamps. For example: DTOpened, DTClosed, DTLastAccessed. This lets me list out all the DTxxxx for a quick reference of all date stamps in a given table.


I work for Texas Instruments, and on their systems they use xxxx_dttm


In order to maintain consistency accross column names, I would suggest you to the following syntax:


I would used a meaningful prefix and _TSMP as a suffix e.g. CREATION_TSMP or LAST_UPDATE_TSMP


For timestamps:

e.g. 2022-09-12T00:00:00Z

  • updated_at
  • created_at

It's concise and if used as a standard there's not confusion.

For dates:

e.g. 2022-09-12

  • updated_on
  • created_on

The same comment from timestamps. It's concise and when used as a standard it's not confusing.

For times without dates which is generally used for scheduling more than recording a time something occurred as that would be a timestamp:

e.g. 12:30:00

  • send_time
  • run_time

Since this is not used nearly as frequently in my experience as at and on using time is sufficient, plus it's short enough.

There was a comment about _at being used for locations. While I can understand that I haven't worked at a business where locations of events was needed. For something like user's ip information we would just have something ip_country, ip_city, etc. For other types of locations we would use location_id. If you need locations and _at is confusing then by all means use a different standard.

I personally care more about consistency and having a standard than a particular standard, as long as there's backing for that standard and not something made up randomly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.