What should I name a DateTime property?

Question

If I have a class that stores a DateTime:

class LogEntry
{
    readonly DateTime dateTime;

    public LogEntry(DateTime dateTime)
    {
        this.dateTime = dateTime;
    }

    public DateTime ?????
    {
        get
        {
            return dateTime;
        }
    }
}

What should I name the DateTime property? Or should I split the property into 2 properties: 1) Date 2) Time?

edit: I was looking for a property name that provides inference that its value is both a date and a time, not a property specific to log entries (e.g., DateCreated doesn't provide any inference that it also shares the time the entry was created and vice versa).

Answer 1

When is a good name in a log.

Answer 2

Anything that's simple, doesn't conflict with other names such as DateTime itself, and is descriptive. Since it's a log entry, you could call it EntryTime.

Answer 3

LogDate
CreatedDate
EntryDate
StarDate // **

Pick a name that you feel describes the property best. And, no, do not split the property.

Answer 4

Whatever makes sense to you (and your team). You could use EntryDateTime as that would make sense. If you're ever going to need the date and time separate, then it would be worth creating separate methods, but there's no need to split the two simply for naming reasons.

Answer 5

You should pick a convention for timestamps in your code base and then stick to that. For example, I call all my timestamps "updated_at" or "created_at". Other options would be CreatedDate and UpdateDate.

Don't split Date and Time into separate properties. The only reason you would do that would be for some kind of optimization for high volume processing where you explicitly identify Date parsing as a bottleneck.

Answer 6

Unlike most suggestions here, I'd use DateCreated because it's intuitive to start typing "date" when you look for the creation date. I also don't think there's a problem only "date" appears in the name and not "time". That's frequent and acceptable.

Answer 7

TimeStamp maybe?

Answer 8

What aboutTimeStamp?

Answer 9

You should pick a descriptive name as what the property does...

If its for a CreateDate then "CreateDate".. pretty self explanatory.

For logging, you can use "LoggedTimeStamp", "LoggedDateTime" etc.

Answer 10

A date is just a coarse grain measure of Time, that lumps 24 hours into the same unit. Put in terms of chickens and eggs, Time comes before date: Time is the physical entity, date is just a unit of measurement. The DateTime datatype helps confuse the issue and leads many people to think of Time as a fraction of Date. This is completely wrong! Einstein didn't talk of Space Date, did he?

Your names should be descriptive of what actually happens, as opposed to detailing the data type (Lezinski, or whatever his name, clearly didn't have intellisense at his disposal).

So either LogTime or EntryTime would be the best names.

Confusing the datatype, the unit of measurement and the physical entity are conceptual errors that lead programmers up the garden path.

And it ain't the garden of Eden.

Answer 11

Assuming LogEntry is used for logging, here is how some other logging platforms do it:

log4net calls it TimeStamp in the LoggingEventData struct.

NLog calls it TimStamp in the LogEventInfo class.

Enterprise Library calls it timeStamp in the LogEntry class.

Microsoft calls it DateTime in the TraceEventCache class (TraceEventCache is passed into TraceListener Trace* calls. DateTime is the time at which the logging message was generated).

Answer 12

The comment on the question says that the question shouldn't be class specific.

The correct answer though is class specific, it doesn't relate to the fact that the property is a DateTime (we already know that it's a date and time because, well, because it is a data and time). The property will exist for a particular reason, and it is that reason that we should consider when naming.

Still, while a request for a non-class specific property name is being made, I offer:

public DateTime TheMomentOfTruth

:)