The typography of dates, times, & filenames

A deep dive into readability in filenames.

Over years of working on creative projects I’ve regularly used screenshots or video captures to document the stages of my work. And while some people might organise these into folders by filetype or some other category, my primary interest has always been the ability to step through them in chronological order regardless of their format.

This has always led me toward storing all files in a single folder within the project. With a naming convention to specifically support chronological browsing.

Here’s a screenshot of the screen-captured files so far from one of my recent projects.

You might note that naming with a date is unnecessary since the file browser lets me order by modified or created date, however, when syncing between different machines and cloud services, I’ve never trusted those dates to remain accurate.

Recently (2024), these design habits aided me in designing the file naming format for my Obsidian handwriting plugin, Ink.

The plugin allows users to create sections of handwriting in their notes while it automatically creates the necessary files for each section in the background. This means that while a user edits one note, several handwriting or drawing files may be created and embedded in it, and the user may also embed these files in other notes as well.

This article describes how I adapted my filenaming habits to make design choices that suit the plugin’s new use case.

It articulates the careful consideration given to date formatting, line length, and general typography attributes of the filenames. To adopt a format with the broadest range of functionality relevant to the files’ use cases.

During my design process, I relied on my internalisation of the important attributes I was solving for, but for context in this article, I’ll start by listing them clearly.

Minimal length.

File managers that display files often provide a limited amount of horizontal space before part of the filename then becomes obstructed. Any consistent filename design, therefore, has to be as short as possible to reduce the possibility of this. If part of the filename becomes hidden, any consideration given to that parts readability is wasted.

Understandable at a glance. Even the first glance.

Making sure all the information needed is present is only part of the problem. Users, who have no context of the information they’re supposed to find should instantly recognise it at a glance. Instant understanding is important because any time that a user spends parsing the information is friction for what they’re actually trying to achieve.

Scannable.

Filenames are browsed in bulk, so they need to be considered in bulk. How does the spacing affect your reading of them when many filenames are stacked one after the other? And how easily can you find a specific file in a group of files which all have the same naming convention?

Note about this article.
The following article dives deep into what you might think of as a very minor design element. If you find yourself wondering why I would spend so long on something so small… know that I didn’t. The decisions and experiments described in this article took about 30 minutes all up, but because they were based on an internalised understanding of several visual design principles and platform behaviours, articulating them makes for a lengthy article.

The foundations

Because files in the plugin are created in the background, I cannot ask the user to take responsibility for the file naming themselves. This means the plugin needs to automatically choose filenames whenever the user creates a new handwriting section.

In the video below, the user creates two handwritten sections in their note. Which means there are two files created elsewhere to hold these sections.

Below you can see that a technical solution for this is simple. We can use an ever-increasing number whenever a file is created. Approaches like this, however, offer the user no aid in understanding when they do eventually look at the files.

1.writing
2.writing
3.writing
4.writing
5.writing
6.writing

To iterate this toward a more human-readable format, dates and times are used to create each filename instead. That’s what we’ll be exploring from here.

The basics of date formatting

Human readable date formats are understood by most people, however, dates that order chronologically when sorted alphanumerically (Like in a file system), involve considerations that most people are unlikely to think about — Present readers excepted of course.

Common date formatting that differs across countries also confuses the issue, so let’s start by touching on the basics of these formats.

In Australia, the commonly used date format is Day/Month/Year, while in America it's Month/Day/Year. Why this is the case is beyond the scope of this article, but I believe both can be related to how we say dates verbally (either "3rd of August", or "August 3rd"), and it makes sense that the year is last, or left off — The year changing the least frequently means it is usually the least pertinent information.

Order the date format by the larger increments first

When working with digital files, however, a common approach is to reverse the format to Year-Month-Day and to use only numbers. This ensures that when ordered alphanumerically, the files automatically fall into chronological order.

For instance, the 14th Feb, 2024, would appear as this…

2024-02-14

Note that we’re using a hyphen now instead of a /
This is because forward slashes are often not supported in filenames.

If this reverse order feels unfamiliar, think of it like how numbers work. Four hundred and twentyseven is written as 427, not 724, because hundreds are a larger increment than tens, and tens are a larger increment than ones. Just like years are a larger increment than months, and months are a larger increment than days.

AlphaNumeric Ordering

We’ve only just begun, however, we’ve already ruled our several potential formats. So let’s take a quick detour to consider why some are not appropriate right off the bat.

We’ll use the below dates for all the examples.

3rd May 2002
18th March 2003
28th June 2004
19th November 2004
1st August 2006
29th June 2008
15th February 2010

First, if we name files exactly like above, then when the files are ordered by filename, they will appear out of order. Like below.

15th February 2010
18th March 2003
19th December 2004
1st August 2006
28th June 2004
29th June 2008
3rd May 2002

Alphanumeric ordering will often look at every digit or letter one at a time starting from the left. This means it will group all the filenames that start with 1 and then all the filenames that start with 2, and so on. Only then will it order by the next digit or letter.

If we reverse the order but still use words, we still run into trouble.

2002 May 3rd
2003 March 18th
2004 December 19th
2004 June 28th
2006 August 1st
2008 June 29th
2010 February 15th

In the above, it looks almost right because the years are grouped correctly, however, look at the entries for 2004. December is listed before June because D comes before J in the alphabet.

To fix this, we have to get rid of the names of the months and use the corresponding numbers instead.

2002-05-03
2003-03-18
2004-06-28
2004-12-19
2006-08-01
2008-06-29
2010-02-15

In the above, we use the format YYYY-MM-DD. This enables all entries to be ordered correctly.

Differentiating multiple files per date

Whenever I create filenames like this manually (Like in my screenshot at the start of the article), I always hope that I only end up with one file per day, but I almost always end up with more than that. This often leaves me having to decide how to differentiate between files created on the same day on the fly.

Let’s avoid that here and consider it right from the start. Especially because it’s almost guaranteed in the context of the Ink plugin.

Appending a number

In some instances, adding a number on the end will suffice. Though it’s a little hard to recognise what it means in the context of the preceding date.

2002-05-03 1
2002-05-03 2
2002-05-03 3

Using brackets can help delineate between the date and number a little better, clearly chunking them to indicate they are two different things and shouldn’t be read as one long string of numbers.

2002-05-03 (1)
2002-05-03 (2)
2002-05-03 (3)

The above example, however, isn’t the whole story. When the first file is created, we don’t necessarily know whether more will follow, so we have a choice. Do we name it 2002-05-03 to keep it cleaner or do we name it 2002-05-03 (1) in anticipation of another occurring?

Using the second option might result in cleaner, more readable files most of the time (depending on how often your files are created), but it would create some slightly inconsistent numbering.

2002-05-03
2002-05-03 (2)
2002-05-03 (3)

A solution that I lean toward (in an automated system), is to name it without the additional numbers first, and then if more files are created later, rename the first file to append a (1).

This isn’t without drawbacks, however, specifically, the user of these files may have created shortcuts or other files that link to them, and automatically renaming them in the background could break those links.

An alternative to adding a number would be to differentiate each file with a descriptor.

2002-05-03 - App idea
2002-05-03 - More philosophy thoughts
2002-05-03 - Philosophy thoughts

This approach, however, creates the work of needing to define the descriptor for each file, and it also makes the ordering within the day susceptible to alphabetical misordering again — Which may or may not be important to the user.

In my use case for the Ink plugin, file creation is automated, so adding a descriptive name wasn’t possible, and while appending a simple number would have worked, I felt that knowing the time of creation would be more beneficial to the plugin’s users — As they could easily identify files they recently created, or files from a writing session they know to have occurred in a morning or an evening.

Appending the time instead

Unlike dates, the time format we’re used to is already in the correct order (Hours:Months:Seconds), but we can't use colons in filenames so let's replace them with a hyphen for now and we'll leave off the seconds.

2002-05-03 - 10-15

Leaving off seconds, means it’s also tempting to leave off minutes, (Feeling that just the hour value is enough) however, while this allows for files created several times per day, it doesn’t accommodate files created several times per hour — Users could even create multiple files per minute at times, either intentionally or unintentionally. The plugin has to be able to handle any of these situations.

Why no seconds?

While I’ve noted that a user could definitely create multiple files per minute, it wouldn’t be very common. So enforcing the visual noise of seconds on every filename just because it might happen occasionally won’t be the most human readable approach.

Still, we need to differentiate between those quickly created files somehow (The plugin can’t just throw an error), but we don’t have to use seconds to do that. Instead, we can appending a number instead (Like we considered previously).

This enables different files created in quick succession to be differentiated by unique filenames, and because it’s still number based, they will still order correctly. And because it chunks them separately to the rest of the time, the visual noise impact is minimal.

2002-05-01 - 08-23 
2002-05-02 - 10-23 
2002-05-04 - 09-47 
2002-05-04 - 16-15 
2002-05-04 - 16-15 (2)

It’s also worth noting that if we had used seconds in the file name, we would have merely kicked the can down the road as well as created another issue.

First, If the user is able to create two files in very quick succession (In less than a second) the files could still be named the same, meaning we’d still need to append a number — It’s not hard to imagine a user quickly clicking to test a plugin and ending up breaking it.

We also don’t want to disable the ability to quickly create files like this as it would force us to take one of two approaches.
1. We could program the plugin to not create files that would conflict, making it appear unresponsive and unreliable.
Or 2. we could also tell the user why the file wasn’t created, which could be disruptive to the user’s flow.

Additionally, perhaps in some contexts, multiple users might create files simultaneously or an API interface might allow for creating files en masse.

Secondly, if we added the seconds, it’s harder to instantly recognise as a time (we’re not used to including seconds), and the appearance of the filename would now easily be confused for two dates instead of a date and a time, as both include three parts.

2002-05-01 - 08-23-16
YYYY-MM-DD - HH-MM-SS

Readability and accessibility

While the previous section described what elements should be included and where, it only very slightly touched on the user experience of working with the files. Meanwhile, through including the pertinent information in the correct order, the list of filenames is growing more and more like series of intimidating and hard-to-read numbers.

So now that we’ve solved the same technical feat that a simple incrementing number achieved, let’s use our new foundation to focus on an improved user experience.

What we’ll consider here touches on a few design principles, but none as much as as scannability. Which, in this case, means the ability to scan your eye across several filenames and quickly interpret them without having to read each one fully and deliberately.

Even though they’re just filenames, there are several attributes we can manipulate to improve readability. Let’s discuss each one separately.

Delineating units

Currently, the format I’ve used above uses only hyphens and spaces. The elements of the date are separated by hyphens, the elements of time are separated by hyphens, and the date and time are separated by a hyphen surrounded by spaces.

2002-05-04 - 09-47

There are, however, many other characters that are valid in filenames we can use. Here are a range of tests with other characters; the goal being to find the characters that work best for the attributes that are important to us.

2023-10-06 - 11-50
20231006 - 1150
2023_10_06 - 11_50
2023-10-06 | 11-50
2023-10-06 + 11-50
2023-10-06 ~ 11-50
2023-10-06~11-50
2023-10-06|11-50
2023-10-06_11-50
2023-10-06 \[11-50]
2023-10-06 (11-50)
2023-10-06 (1150)
2023.10.06_11.50
2023.10.06_11.50
2023.10.06 - 11.50
2023.10.06 (11.50)
2023.10.06[11.50]

The two that I feel showed the most promise in readability are below.

Periods and a hyphen:

2023.10.06 - 11.50

Periods and brackets:

2023.10.06 (11.50)

Both of these replace the hyphens within the date and time sections with periods. This reduces the visual noise while also allowing the hyphen, if used, to have a singular meaning.

In deciding between the two, it’s also important to consider how it will appear in different contexts. For instance, if multiple files with the same time are created, as we explored before, how will they look with the additional number appended?

Hyphenated:

2023.10.06 - 11.50 (2)

Bracketed:

2023.10.06 (11.50) (2)

In the bracketed version above, you’ll notice that it now has 2 sets of brackets and is starting to feel slightly more technical and complex as a result. The alternative choice, even with the bracketed number, still keeps an air of simplicity by having three clearly differentiable sections.

12 vs 24 hour time

The choice between 12-hour time and 24-hour time has almost been made already. This is because we want the files to display in chronological order, which 24-hour time gives, whereas 12-hour time would cause times from the afternoon to mix inbetween times from the morning when ordered alphanumerically.

2023.10.06 - 2.00am
2023.10.06 - 2.55pm
2023.10.06 - 8.12pm
2023.10.06 - 8.30am
2023.10.06 - 11.55am

But while 24 hour time doesn’t have the issue shown above, it does have another issue. Even though a user can easily figure out that the first part is a date and the last part must therefore be time, it often still requires a subtle decision to interpret it that way.

12 hour time, on the other hand, has an am or pm to clearly indicate it‘s a time at a glance — An indicator that 24 hour time doesn’t have, which creates friction.

2023.10.06 - 2.00
2023.10.06 - 8.30
2023.10.06 - 11.55
2023.10.06 - 14.55
2023.10.06 - 20.12

In different apps, and contexts, numbers that look similar to this can also mean different things. Even if you use these files daily and know the format, you still have to adopt that correct mindset each time you look at them. With 12-hour time, however, you see a format that means time in any context. The context switch is almost hardwired and therefore means less friction.

2023.10.06 - 8.30am
2023.10.06 - 11.55p

In attempting to prioritise this, one exploration I considered was to use 12-hour time, but place the am and pm before the time. This maintains the order because a comes before p in the alphabet.

2023.10.06 - am 2.00
2023.10.06 - am 8.30
2023.10.06 - am 11.55
2023.10.06 - pm 2.55
2023.10.06 - pm 8.12

This, however, is not very successful. It’s so non-standard that it throws you as a reader and possibly even makes you question whether the am and pm are part of the numbers at the end or the numbers at the start.

The final format I chose, however, is also non-standard. I added am and pm onto the 24-hour time format.

2023.10.06 - 2.00am
2023.10.06 - 8.30am
2023.10.06 - 11.55am
2023.10.06 - 14.55pm
2023.10.06 - 20.12pm

By combining these together, I’m able to force the user to instantly recognise the number as a time, while also maintaining the correct ordering of the files.

This doesn’t mean it introduces no friction. When the user eventually realises what I’ve done here (They may not realise straight away), they might think “This developer doesn’t know how 24-hour time works”. This thought can both distract them slightly from their task as well as slightly degrade sentiment toward the product, however, I’ve made the gamble that it adds less friction than it alleviates.

Months as words

Similar to the use of am and pm for quicker recognition, I pondered whether month names could be incorporated. If I could articulate months as words, then if someone wants to find May's files and May's number doesn't immediately come to them (It’s 5), they can do it instantly by the month names and without having to count.

If only we could simply replace the month numbers with words. It would be beautiful. But as we’ve seen before, the files would then sort into the wrong order.

2004.August.28
2004.June.19
2004.March.18

We might instead consider combining the month numbers at the front of the words, but while the numbers fix the order, they also become confusing visual noise.

2004-03.March-18
2004-06.June-19
2004-08.August-28

2004-03[March]-18
2004-06[June]-19
2004-08[August]-28

2004-03 (March) 18
2004-06 (June) 19
2004-08 (August) 28

2004-03 - March 18
2004-06 - June 19
2004-08 - August 28

2004-03 - Mar 18
2004-06 - Jun 19
2004-08 - Aug 28

Above are several variations I tried, and while the last one feels clean and informative, it’s still not immediately clear why there’s an extra number after the year when there’s already a month name. It’s also made the filename significantly longer. Especially once we add the time back in.

2004-03 - Mar 18 - 8.05am
2004-06 - Jun 19 - 9.15am
2004-08 - Aug 28 - 13.32pm

Ultimately I felt the negatives of a longer filename and a slightly confusing month number/name repetition made the names not worth integrating for my plugin.

Note on length.
Filenames in Obsidian (Which this plugin is used in), are mostly viewed in a narrow side panel. Too long a filename, therefore, would cause the end of the filename to get truncated and not display. This is often the key trade-off with all of this — Is it worth having extra month information if the time becomes completely hidden? Which is more important to ensure the user can see?

Leading zero

In the above examples, I’ve temporarily ignored decisions around what’s usually referred to as leading zeros. Below, you can see a comparison of the two possibilities.

No leading zeros:

2023.2.6 - 8.05am

With leading zeros:

2023.02.06 - 08.05am

You’ll notice that the month, day, and hour values can have a zero before their digit to pad them out to two digits, or they can not have it. Either way, we still find it comfortable to interpret them as dates and times.

You may not have realised, however, that I didn’t remove the leading zero from the minutes value. If I did this, it would start to look more foreign and less like a time, and it would also be easily misinterpreted as a decimal value — In this case, making you think it’s half past 8 rather than 5 minutes past 8.

2023.2.6 - 8.5am

On some platforms (mainly older ones), leading zeros are necessary for ordering. This is because alphanumeric ordering often works one digit at a time. Meaning that 12 would be ordered before 3 because the first digits, 1 and 3 are compared first, and 1 is lower than 3.

2023.12.6
2023.3.6

Leading zeros fix this when platforms can’t automatically adjust. The leading zero forces the 1 to be compared with the 0 and therefore order correctly.

2023.03.6
2023.12.6

Depending on the format of your numbering and the platforms handling of it, leading zeros might be necessary, but in Obsidian, it orders correctly either way, so it’s a choice we can make based on other factors.

I’ve found that most modern operating systems and apps work fine without leading zeros now, but it’s important to be aware that it can be a problem.

Aside from ordering, leading zeros also affect the horizontal positioning of text that comes after it. Not including leading zeros can create a more ragged appearance — Where similar values across each row become misaligned.

2023.2.6 - 11.55
2023.10.10 - 8.30
2023.12.4 - 14.55
2023.12.17 - 20.12

In the example above, because the 2, 6, and 4 on the 1st and 3rd lines don’t have leading zeros, the times (and some of the days) become misaligned. This makes it more difficult to run your eye down the days or times and compare them — Because you might be comparing the wrong digits. To combat this, you have to scan slower to ensure you’re comparing accurately.

With leading zeros, however, the times and days stay aligned and you can scan down them very quickly with minimal risk of mistakenly comparing the wrong number.

2023.02.06 - 11.55
2023.10.10 - 08.30
2023.12.04 - 14.55
2023.12.17 - 20.12

While this looks neater and the rationale makes sense, however, it doesn’t consider the specific needs of the users of Ink. In other circumstances, users may want to compare times across different days, or days across different months, but in my plugin, comparing a time across days is unlikely to be of use.

In the Ink plugin, if a user is looking down a list of these files, it’s more likely that they’re simply scanning down all the files by day or by month and it’s not important for them to compare across these thresholds. This means that the misalignment can be an asset that helps navigation by emphasising the division of days and months.

In the example below, while the times may be misaligned across days, times on the same day still remain aligned. The ragged appearance, therefore, makes time comparisons easy on the same day while also using the misalignments to emphasise the boundaries of each day.

2023.2.6 - 9.45am
2023.2.6 - 11.55am
2023.2.6 - 12.05pm
2023.2.6 - 13.01pm
2023.7.13 - 8.30am
2023.7.13 - 8.42am
2023.9.7 - 6.23am
2023.9.7 - 7.55am
2023.9.7 - 14.55pm
2023.13.13 - 19.46pm
2023.13.13 - 20.12pm
2023.13.13 - 20.19pm

All said and done, this comes down to a comparison of what’s the most important feature:
Comparison of times across different days OR visual grouping of consistent days.

Solidifying an approach

We’ve spent a fair amount of time here discussing decisions around format and spacing in filenames. So I commend you if you’ve made it this far.

As with any design decisions, the more commonly you work with the elements your designing for, the quicker it becomes to recognise when you can lean on existing assumptions and when you should dig a little deeper.

Remember that while these decisions suit my Ink plugin, if building for a different use case, different considerations may be at play.

That being said, my final format (as of June 2024) is below. It reverses the date, appends am/pm to 24 hour time, and uses no leading zeros in months, days, or hours. It also uses a bracketed number instead of seconds to differentiate files created within the same minute.

2023.2.6 - 9.45am
2023.2.6 - 11.55am
2023.2.6 - 12.05pm
2023.2.6 - 13.01pm
2023.7.13 - 8.30am
2023.7.13 - 8.30am (2)
2023.7.13 - 8.42am
2023.9.7 - 6.23am
2023.9.7 - 7.55am
2023.9.7 - 14.55pm
2023.13.13 - 19.46pm
2023.13.13 - 20.12pm
2023.13.13 - 20.19pm

Thanks…

I hope you’ve enjoyed this little window into my mind.

I like to dissect and speculate on design and development. Digging into subtle details and implications, and exploring broad perspectives and potential paradigm shifts.

If you enjoyed this post, consider following to receive posts like these once a month. Or find me on Threads, Bluesky, Mastodon, or X for more diverse posts about ongoing projects.