Previous Section
Next Section
Toggle Preview Environment
Previous Platform
Next Platform
command +
Scroll to Top
command +
Scroll to Bottom

Scheduled events and other timestamps are all over the Hudl interface. Applying a consistent format to those details is key to building a cohesive experience.

One thing to keep in mind with everything below: moment.js isn’t required, but definitely preferred for the sake of uniformity—at least for now.


More often than not, you’ll only need month, day and year. The day should always be an Arabic figure (Aug 10), never ordinal (Aug 10th).

Months should be abbreviated to the first three letters (handled by moment.js), but the year will always be the full four digits.

We realize the order of these elements changes depending on locale. Rather than list all possible arrangements, we’re trusting moment.js to call those shots, as well.


Sept. 28th, 2019

31 October ’19


Sep 28, 2019

31 Oct 2019

  • Always use Arabic figures, never ordinal. (No 1st, 2nd, etc.)
  • Abbreviated months should be three letters, no period.
  • Never shorten the year. It could get confused with the actual day.

Numbers Only

Avoid the numbers-only format whenever possible. For one thing, it’s not as clear, especially when numbers could represent day or month. For another, there’s no good answer re: whether or not we put 0 before a single-digit month or day. Remember, we’re going for consistency.





Sep 10, 2019

9 Oct 2019

  • Don't rely on numbers to represent a month.
  • Keep in mind how the order may change after localization.

If you have a case where all-numbers is the better option, talk to Uniform.

Days of the Week

In the case of full schedules and any upcoming event, include day of the week.

When possible, spell out the day. If it must be abbreviated, trim to three letters with no period (same as all other abbreviations).


Jun 17, 2019

Jun 20, 2019

Jun 23, 2019


Monday, Jun 17, 2019

Thursday, Jun 20, 2019

Sunday, Jun 23, 2019

  • Differentiate otherwise identical items with days of the week.
  • Spell out the day whenever possible.


Whenever you include time, it should come with am or pm. Refer to all times with actual numbers—no exceptions for noon or midnight.

Avoid the 24-hour format (it’s why the am/pm is so important). Because durations occasionally appear in the product, we want to avoid any possible confusion of the actual time being a video length.


Oct 25, 10:30 A.M.

Wednesday, 25 Oct at noon

22 Feb, 15:05


Oct 25, 10:30am

Wednesday, 25 Oct, 12:00pm

22 Feb, 3:05pm

  • Always include am and pm, lowercase with no periods.
  • Don’t add a space before either.

Time Zone

Only include time zone when the times pertain to a specific place, like Hudl HQ. All other times displayed in schedules or feeds can be implied as local.

To avoid any Daylight Saving confusion, don’t include S(tandard) or D(aylight) in the time zone abbreviation. That means Hudl HQ will always be CT, no matter the time of year.


Next game: Saturday, Aug 15, 7:00pm PDT

Contact Hudl Support 8:00am to 7:00pm, M–F.


Next game: Saturday, Aug 15, 7:00pm

Contact Hudl Support 8:00am to 7:00pm CT, M–F.

  • Only use time zones when the location may not be local.
  • Ignore any mention of DST to avoid outdated or incorrect hours.

You can find other office time zones here.

Life Span

For longer life span items like feed cards and exchanges, it’s important to clearly communicate exactly when a thing was created or shared.

Note that the concept of “life span” does not apply to schedules and planned events.

Avoid putting about before these timestamps. The user shouldn’t second-guess how old an item really is.

  • If it’s new within the hour, count the minute, e.g., 13 minutes ago. (This is the only time we’ll use ago.)
  • For anything shared or created that day, use only the time—2:16pm.
  • If it was yesterday, say so! Yesterday at 2:16pm.
  • For anything in the last week, mention the day, not the date—Wednesday at 2:16pm.
  • Once that week is up, use the date instead, e.g., Mar 6 at 2:16pm.
  • After a month, drop the time to simply say Mar 6.
  • After a year, add the year—Mar 6, 2019.

When we generalize with “one week ago” or “three months ago”, timelines become ambiguous and the user could lose track of what’s relevant when. Providing the right amount of detail makes it easier for them to reference past interactions and plan new ones accordingly.


Durations should always include digits for minutes and seconds—even for those under a minute long. This applies not only to the length of a video, but also to how long a user watches video (found in team management).









  • Anything 59 seconds or less should still include a zero in the minute slot.
  • Durations under 10 minutes can be displayed as a single digit, no need to put a zero on the front.
  • Hour digits are not required until the video (or user activity) hits the hour mark. If it’s likely listed items will reach an hour in length, a zero may be added for consistent space—just make sure the view isn’t full of empty hours.
  • Milliseconds are also not required and shouldn’t be used in a static display of time. If you want to display time elapsed as a video plays, be sure to set off the milliseconds with a period rather than a colon.
  • Never use h, m, or s for hours, minutes and seconds. Stick to the colon format for everything.