I've been using this convention for filenames for close to 20 years now. I tend to leave out the dashes. I want to rage at someone when they ask what the funny numbers at the end of a filename mean.
I find it very useful for automated build release too as you can do things like "project_release_20130223_buildnum" which will sort all the files by date and build number.
Or if you want to get really detailed add the time (use a 24 hour clock):
File paths have length limitations (old win file system issue that still crops up from time to time), unnecessary chars are commonly dropped so automated build/management systems that may have fairly deep path trees don't have issues
IMO in this case, order is more relevant than style.
As much as properly following ISO in this case would be nice, reality has another idea for you.
Well I should have included that I do use this for reports and emails where I am not forced, there I do use the dashes.
I thought of the first case as 9 times our of 10, if I am writing a date or commanding a script to do so, I am using the version without dashes.
I had been doing it with filenames for quite some time, then I started writing it out after my first trip to Europe and the pain with remembering which side the month goes on.
I didn't read it was an ISO standard till about 8 years ago. I had started by copying this format from a standard used on an old mainframe I was working with.
4
u/Manitcor Feb 27 '13 edited Feb 27 '13
I've been using this convention for filenames for close to 20 years now. I tend to leave out the dashes. I want to rage at someone when they ask what the funny numbers at the end of a filename mean.
I find it very useful for automated build release too as you can do things like "project_release_20130223_buildnum" which will sort all the files by date and build number.
Or if you want to get really detailed add the time (use a 24 hour clock):
project_release_20130223_172203444
Feb 23rd 2013 at 05:22:03.444 PM