You know who you are. You are my friends, colleagues, and clients. You’re really smart about how to use computers and stuff. You’re great people.
But I just can’t stand it when you put dates in your file names. Whether you put dashes between the numbers, use two- or four-digit years, I still can’t stand it.
There are sooo many problems with this technique. Let me count the ways:
- It’s hard to read. (You have to think just a little bit to interpret the date, don’t you? If you have multiple files named in this manner right next to each other, you have to think a little bit to figure out which is the newer version)
- It doesn’t sort correctly when you sort by filename over the December-January divide (Unless you begin the filename with the year, which of course just makes it even harder to read — for example, what date is 06-05-07?)
- What if you make two versions on the same day? (Yes, you have to start appending “_v1” and such. Yuck!)
- Conversely, what if you don’t want to generate a whole new version of a file, but you want to work on it on multiple days? (You have to remember to change the filename to the new date you save it, otherwise you end up with a file with one date in the filename and another in the date metadata.)
- It doesn’t work well internationally. (Is 02032007 in February or March?)
Hard-coding the date into the filename field is the equivalent, in HTML terms, of using the font tag instead of the h2 tag for your article title. It’s semantic abuse.
What particularly annoys me about this is that files already have date metadata attached to them. This is true on Mac and Windows file systems. Yes there is the occasional problem where a file’s date metadata is lost, for example when uploading/downloading from a server or burning to a disk. But this is pretty rare these days, isn’t it?
The solution is simple: Just change the version number in the file name, and let the operating system handle the date part automatically. It’s really that simple. If you really must hard code the date because you’re afraid it will get altered in transit, just do so in the document itself, for example on the title page or in the footer.
Whatever your company’s version numbering syntax is, you simply append that number to the filename and increment it every time you save a new version. You won’t miss your old date-in-the-title format at all; you can still sort by date just fine anytime you want, no problem.
I mean, isn’t this listing a lot easier to read than the one above? To me it’s like night and day.
- It’s easy to parse when browsing a long directory of files.
- It sorts perfectly both by name and by date.
- There is no confusion about the date — it’s right there in whatever format your OS is configured to display.
- It allows multiple versions on the same day (or the same version on multiple days)
- It’s easy to talk about whenever you’re in awkward phone conversations about finding the right version of a file.
Basically it’s just short and sweet, which is the best reason of all.
Comments
27 responses to “Stop Putting Dates in File Names!”
Are there any situations where the metadata is hard to see and is helpful in the file name? I don’t think it’s a “never” situation.
If you are browsing images (or videos) in Windows, you want the thumbnail view, perhaps, and that takes away the date info.
If you are looking at an email attachment, say in Eudora (or maybe other apps), you see the file name and type but none of the other info.
The problem is not people, is it?
I have to confess that I do put the date in the filename occasionally. It’s almost never on a document I’m working on, but if I backup a whole folder full of stuff I’ll do something like this:
webapp-backup-2007mar06
It’s too easy to loose the backup date on a whole folder full of stuff. This technique has the added benefit of being sortable and international friendly.
I also sometimes throw a textfile in there titled “why-backed-up.txt” that explains what changed right after I backed it up.
Of course the best solution is to use a version control system, but I digress.
@Steve & Chris: You both raise good points, but again simply putting the version number in the filename solves all of these problems.
And, for the diligent archivist, detective, or lawyer’s needs, many document formats include date metadata in the file itself (in Word, click “File > Properties > Statistics” to see the permanent metadata), independent of what the file system writes to the file.
But as per Steve’s point, yes, this is not a “never” thing. I was thinking specifically about the idea of using the date as a type of version control for what are essentially iterations of the same document. But there are other contexts in which a date is okay, I think. For example, if the document is specifically an article about what happened on March 3; or if it’s a weekly report about what happened in the week of March 3, then yes it’s perfectly appropriate to put the date in the title. In this example, the date is in fact the subject of the document, which is not the same thing as date metadata.
I wish I could ween my employers off this habit.
OMG… how did you hack into my computer? =)
And how do I set the date when it’s wrong? I have photos from 1970, but since I had scanned them last month their modification/creation date is totally useless.
Also, is it really impossible to lose the modification/creation date? When you copy a file to your backup DVD/HDD the creation date is lost. When you modify a file’s meta-data (ID3 tags, EXIF, etc.) the modification data is lost. Now, do you understand why people keep dates in their file names? You can lose that data, otherwise. They don’t trust their computer.
There is no “original creation date” attribute which can be set arbitrarily and which survives when the file is copied or modified. One could argue that “creation date” should do this job, but at least on Windows it doesn’t.
I used YYYYMMDD_filename and it sorts fine. It is much easier than having to use a second step of checking the modification date.
I go for the YYYYMMDD in filenames for sort order. I only put dates in filenames when it helps locate a particular file. For example, my timesheets are completed weekly, based on a ‘week ending’ date. So I have files called Timesheet_20070304.
When I started reading the article, I thought I was going to disagree – simply because I have a valid use for dates in filenames. By the end, I’m mostly in agreement.
As has been mentioned, for photos etc, filssystem date metadata can be a bit fragile, especially cross platform, so putting dates into photo filenames seems acceptable to me. No worse than writing dates or notes on the back of real photos. And no less readable than the filenames given to photos by the average digital camera !
When I need to keep track of dates, I tend to put the date (YYYYMMDD) at the beginning of filename with a space before the filename. Visually, it may as well be another column.
90% of the time I solve this problem by using Subversion, but when I’m doing something quick and dirty, I date it. Metadata just isn’t trustworthy enough in modern operating systems, particularly when you’re working with more than one platform on a regular basis.
The date in the filename is a “handle” for ID. Look at how the SSN and Driver’s # have been ID. “YYYYMMDD” sorts well. The milennium cured us of the YYDDMM.
Do a search for a filename, don’t you want the added feature of search by date you named the file? If you use the metadata, it may or may not be the date you want, as what you wanted to document for the file.
At my job, I take minutes from all the meetings I have with the people involved in various projects. Often, people email me and ask me to resend a doc of minuets from a particular day, and in this instance it makes it easy for me to date docs. Usually I type up minutes from notes a day or two after the meeting, and often there’s a couple of meetings in a week, so to have a chronologically ordered filing system without the date in the title would be a bit hard to work out.
In general, though, I agree. It’s like when people put full urls into Google. Or, even worse, I once saw someone google Google!
The only time I’ll put a date into a filename, is when the date *is* the filename. I have some very complex workflows with my photography, and I rename the files to the EXIF date, not the Last Modified date, then just append a counter to the end of the filename. When you’re sorting through non-text files (music, photos, video), the current file managers SUCK, and you’ll want to use a better tool to sort through your images/videos/etc. I suggest Lightroom/iPhoto/Aperture/iView for images, and iTunes/VLC for your video assets. You simply can’t tell what something is from a 256×256 icon, you can only get “maybe”.
I also use various other bits of metadata to keep my files in order (EXIF/ANPA/personal tags, etc). I’ll sort by last-mod often, but I also label “the current” file or folder green, so I can very easily see that “this is the one I want”, regardless of file manager mode.
I do the same thing for folders. Current clients are green, clients that I’m not actively working on, but may need to retrieve quickly are yellow, and older stuff is simply not labeled. Sometimes, when versioning (outside a version system like CVS/Subversion) I find I have too many old copies, and I just throw them into an “OLD” folder, and keep the last 3-4 versions outside of it.
As for versioning, the next version of MacOS X will have access to ZFS, a new filesystem by Sun. In effect, it gives you transparant infinite versioning without the need for a versioning system like CVS. I think this will also help keep things under control.
@CM: Yeah, that last thought ties together this and another recent graphpaper.com post: How come version control isn’t built into every operating system? What’s with that? The “x-factor” of having enough hard drive space is now a moot point. I will def. want to learn more about this ZFS thing.
I also insert timestamps into filenames and I find when we’re iterating quickly that the v05 convention is less useful. The long way is more reassuring to designers when you consider to get to the date in the file, you have to trigger another action to get to it, and, when you’re working on multiple projects with multiple files, v05 doesn’t tell you what the timestamp is when we’re sending files, but I would agree that for our recipients, probably would be best to receive something like v05.
Let’s give it a shot and see how it goes!
I admit my internal desire to want to be organized makes me one of these evil doers at our office place.
This sort of version control isn’t an automatic win for everyone, since there are still people in the world who need to conserve their hard drives. Ask some poor film student who’s trying to edit her film on a crappy iBook how she’d feel about her filesystem automatically copying her Final Cut Pro documents every time she made some minor change.
As for putting dates in documents, I’d say that yeah, it’s usually a poor organizational practice. I almost never do it personally, and then I just view all my folders on my Mac in reverse-date order. Works pretty well for me.
And the biggest problem, I’d imagine, with automatically putting the date in everything, is that 99% of the time you only care about the most recent version, so carrying around that spammy date info is just a waste.
If your co-workers had a high enough level of tech-comfort, maybe you could setup Subversion to make automatic commits every night, and then you could demo to them that all their versions can always be retrieved. Though I guess that’d be pretty ambitious.
Personally, I work in programming, and there are lots of cases where I do actually want dates in the filename. Like, at work I have a big /data/ directory with timestamped database dumps, with filenames like Website.sql.2007-02-01.gzip. You can make the case that this is already present in the mtime, but metadata does get lost sometime. And when I send a co-worker this file over Bonjour I want him to know instantly when this snapshot was taken.
Of course, that’s probably not the specific case you had in mind.
Worse than dates is including the word “final” in a file name. That guarantees that additional changes will be required, resulting in files named “…FINALv03b” and “…FINAL07-03-07”.
@Rick: YES!
I disagree with a lot of the points. As a systemoperator I see metadata getting fucked a lot. I even have files that according to their metadata were created decades before the program that could create that file was invented. But apart from that there are some more practical problems.
I generate a Word document with a report for my daily duties to report to the client. Firstly, if I do NOT include the date in YYYYMMDD format at the beginning of the filename but simply call it ‘report 53’ (if it’s the 53rd report) the client would get confused and have a harder time to look up which report is for what day (since mostly they only look at file names, as do I). It’ll sort things just as nicely, but it won’t make it any easier to read the contains of a folder.
Secondly a LOT of user unfortunately don’t even know you can sort by date, let alone file properties like its creation date are saved. It’s easy to say “ha well they should learn to be 1337 like me!”, but unforunately that doesn’t work in the real world. (I wish, would make my job a lot easier!).
Thirdly, if for some reason I choose to create a series of blank template reports, they all get the same creation date. If I then use these blank reports for my daily chores, yes it gets a nice date when it was edited. But if a user opens this report, changes one letter and accidentally hits save, there is really NO way to tell for what day the report is by just looking at the file and its properties. Am I supposed to write-protect every file I make then?
Then again, file names get edited all the time too (but not so easily by accident). Because there is no good technical way to *ensure* these kinds of data, I would say having the date in the file name is a good redundancy to prevent any problems from having just the file properties. That is until there’s a really fail-safe system to prevent these problems. From what I’ve noticed the best fail-safe system now is to just have good agreements with your colleagues and company what the best way to file data is, also in relation to clients.
I guess a similar rant could be held for people who don’t fill in their id3 data for mp3-files but after a while, you just give up and start editing them yourself.
Stop Using Windows 😉
@paolo: Not sure about how Linux users generally behave, if they can be generalized, but in my experience Mac users are the biggest culprits of this. I suspect it’s because they’re less likely to use any folder view modes where the date is displayed next to the filename. In icon view mode, for example, all of the metadata is hidden. It pains me to no end that icon view mode is the default view for both Macs and Windows computers. It’s the first thing I change when I get a new system.
In fact, I suspect that icon view mode is the main origin of the date-in-filename practice.
I agree you don’t need to put the date on the file name, most times.
The one I find hilarious, is when my students eletronically hand-in their assignments with names that include ‘final version’, which keeps changing, such as:
design-assignment4-FINAL-version.pdf
and then email me another version named:
design-assignment4-FINALFINAL.pdf
The day of the presentation, they actually show:
design-assignment4-FINALFINAL-THIS-ONE.pdf
I agree. I’m going to stop putting in dates from now on. Also can’t stand it when people put “FINAL-FINAL-FINAL” in the filename. When I number files I don’t use the “v” in v2, v2, v3, and I usually pad with zeros to account for a reasonable amount of increments. Last I checked, some systems will sort 10 above 2??
Whatever-2007-03-01-01.file
That’s how I roll; ISO-compliant all the way.
B-sting’s right. People often don’t know how to find date metadata (most default views don’t display it). Flawed systems obscure, misinterpret or omit them.
Unfortunately, it’s a lowest-common-denominator world if you’re widely exchanging documents.
P.S. Obviously, I don’t do this on my private files.
Dates in file names can be very helpful. When working on a project, it is an extremely easy way to know the relevancy of the file and what it might contain.
May I say that overall, I think you just like to object for the sake of objecting.
I take meeting minutes for several different committees, and I like to put the date in the file name.
I use xxYYMMDDr, where xx is the committee and r is the draft revision letter.
It sorts without issue, and it is concise, easily remembered, and readily identifiable to me as minutes.
I use this same scheme to identify DVD’s of meetings.
I think this article concentrates on using the date as a version control mechanism and misses a good few points.
As stated, so many times here, YYYYMMDD sorts fine.
Operating system metadata is unreliable; many systems can’t store a creation date for a file. Furthermore, after running Windows systems over a few years you’ll start to notice you get files with modification dates before the dates the files were apparently created (meaning the creation date is useless and refers the file as a file system enitity and not the files contents).
Application metadata is just that, application specific. If you can store some date metadata in Word, that’s fine if you use Word, useless if you don’t. EXIF data is easily wiped by an application that doesn’t support it or by saving the image as non-JPEG.
As for -v1,v2 in a filename, that’s great for simple version control, but no good if the filename cannot change, for example; some types of source code. You need some kind of CVS, or document management.
Sometimes the date in a filename is appropriate, for example a letter written/sent on a particular date. Sometimes it’s the best solution in a non ideal world (backup time stamps).
Ideally these deficiencies would be addressed in the operating system, but they aren’t. And the whole implementation of filenames is slightly flawed; any Apple user will ask why Windows encodes the file type as part of the filename…
I think dates in filenames occur because of limitations and defects in systems, and sometimes because they are appropriate and not because of user incompetence.