DateTime display with some long day & time formats can show up truncated on Boom. This issue has arisen out of the alarm time indication  on Date time display but it is separate from the alarm issue. Related discussions have been carried separately on campfire and the early beta forum.

Some long day & time formats cause truncations on Boom depending on text size and also language (I have only looked at English but German is probably worse) on the DateTime screensaver.

In particular - and the long date format with full day and month spelling (e.g WWWWW, DD MMMM YYYY) cause problems with dates such as "Wednesday, 24 September 2008" which gets truncated to "Wednesday, 24 Septembe" on Boom display  and the longer Time format such as 12 hr hh:mm:ss PM or h:mm:ss PM when the hours are in double digits - the AM/PM gets truncated on large size display.  Also even if time format exactly fits display- the single char alarm and snooze indicator would get overwritten by AM/PM so a 12hr time display needs to take up fewer pixels or else do not display these long time formats (probably not acceptable).  

It is probably not acceptable to remove some formats so formats have to be modified to display on Boom. 

So possible options for displaying Time on large fonts 
1. Substitute another standard format in certain conditions (e.g. change "hh:mm:ss pm" to "hh:mm pm" for large font on Boom)
2. Time length in pixels is a problem with large fonts - so have special narrow digits in large fonts used on Boom. 

The time issue is simple since it only affect one font size.   The date format issue affects all size so special font is not an option  The choice seems to be to subsitute a different format when using Narrow displays (e.g. use "WWW" instead of "WWWW" , use "MMM" instead of "MMMM" , use "YY" instead of "YYYY") ideally the code should check pixel length of display to make best choice and make allowances for Alarm and snooze indicators  

Part of the solution to this issue requires guidelines on formatting issues (e.g. truncation, overlapping) of standard functionality in the Boom context (i.e. narrow displays).  The Guidelines would then enable general decisions to be made without having to argue the options in each case. Typically whether 
* to remove functionality
* to modify existing formats (perhaps on a per display type basis)
* to accept compromised display 

An example (which could be logged as a bug) where some change is needed with "Show Buffer fullness" display when playing a stream of known duration (e.g. podcast, BBC/NPR archive program).

The Buffer fullness display on SB3 is something like "Playing Now  123/10.0 seconds" on Boom it becomes "Playin  123/10.0 seconds".  Then sensible approach would be shorten "Seconds" to "Secs" and not overwrite "Playing Now".  Guidelines would help this issue without have to discuss it.