Skip to the content

Kansas State University

Calendars at K-State

K-State's central website provides a way to publish university event information as part of a university calendar as well as on the K-State homepage.

Publishing your events to the central calendar has several advantages:

  • Calendars are in a consistent format.
  • Calendars from several sources can be integrated into one combined calendar.
  • A familiar calendar navigation aid is placed at the top of every calendar.
  • Calendars are linked from a central location, so people can find your calendar easily. In particular, calendars are From the K-State homepage, you can reach the calendars by selecting the Calendar link near the top left side of the page.
  • Most calendar events are visible on the K-State homepage as "Today at K-State" events and "Upcoming events".

Submitting events to the calendar

To add your information to a calendar, the easiest option is to submit the calendar event form with your event information. Additionally, you can submit questions, events, or multiple events to

  • Please allow at least two working days before the desired posting date.
  • Include traditional event information: title, time, day, location, brief description, and who it's sponsored by.
  • Include the website for the event. Many events have more information than can be posted in a brief event listing. Linking to a website allows the event owner to provide many more details.

Creating your own calendar

However, if you have more than an occasional event, it is better to set up your own calendar. To create a calendar, two files are required:

  • Calendar data file
  • Template file

For these examples, assume that you are providing files for a department with a department code of dept and have chosen to call your calendar events.

Calendar data file basics

The calendar data file is named events.caldata, and it is stored in the department's web space directory, /usr/local/data/www/dept.

The format of the calendar data file is a single HTML definition list:

<dd>description of the event
<dd>description of the event

Several formats are acceptable for the date field:

April 30, 2008 This is the normal format.
April 30 A missing year defaults to the last year specified.
apr 30, 2008 Only 3 chars, case insensitive, of strings used.
Sunday, April 30, 2008 Day-of-week string is ignored; it doesn't matter even if the day of week is wrong.
Sunday April 30 2008 Commas and blanks are equivalent
April 1, 2008 -- May 2, 2008 Any two dates separated by '--' are a range. The event is duplicated for each date in the range, inclusive.

Other notes about the calendar data file:

  • There is no limit to the number of events that can be listed on a single day or the total number of events in a file.
  • Do not include any HTML tags in the date field. The date field is bold when displayed, but this bolding is added by the calendar formatting process.
  • You can put multiple events on a single date by using multiple <dd> tags. You could also repeat the date, i.e., use multiple <dt> and <dd> tags.
    <dd>description of the first event on this date
    <dd>description of the second event on this date
  • Events do not have to be in chronological order within the calendar data files.
  • Everything in the calendar data file before the first <dl> tag and after the first </dl> tag is ignored.
  • The program that processes the calendar data file does not understand everything about HTML, and thus differences that do not matter to HTML may matter to a calendar file. In particular, the <DL>, <DT>, <DD>, and </DL> tags must all begin in column 1. If you use an HTML editor program to change the calendar file, be sure it produces files suitable for calendar data files. When in doubt, you can always check the file with a Unix editor such as vi or pico.
  • Don't try to grab attention by making the entire text of your event bold, all caps, larger, or a different color.
Wording of Event Text

The difficult part of creating a calendar file isn't the mechanics of getting the data into the proper HTML format. Instead, the emphasis is on wording the events in a clear, concise, and useful format.

  • Each event description must stand alone. Remember that each event will be processed into the university calendar, and thus will be seen without the context of the other events in your calendar.
  • Each event must be short. There is no enforced limit, but perhaps 30-40 words is the maximum. You can, of course, use a link to another web page with a more complete description.
  • Don't duplicate events of other calendars if your calendar is to be included in the university calendar. For example, the start of classes may be important to your organization. However, such events are already included in the Academic Calendar provided by the Registrar.
  • Be sure to include the basics:
    • date
    • title
    • time
    • location
    • brief description
    • sponsoring unit
  • Also consider what additional information may be required for a complete event. Is there an admission charge? Is registration necessary? Is this for students only?
  • If possible, always link your event title to a website with more details.
Template file

The template file will be provided for you when you're ready for production. The template, named events-template.html contains the HTML code that surrounds the events. It uses the K-State calendar template which includes a visual calendar at the top.

This templates is only used when the calendar is viewed as its own calendar. When the calendar events are put into the university calendar, then the university calendar's template file is used.

Getting your calendar into production

To get your calendar added to the list of calendars, and possibly included in the University Calendar, contact

Calendar example

Suppose your department code is dept, and you are creating a calendar file named events. In the simplest case, you need to create two files: a calendar data file and a template file.

Here is an example calendar data file:

<dt> January 1, 2008
<dd> Happy New Year!
<dt> January 16, 2008
<dd> Classes begin.

For additional examples, see the existing calendars, most of which are in


Advanced Features

There can be multiple files that are all put together into one event database. All files of the form events*.caldata are read. For example, files named events-fall1996.caldata, events-regular.caldata, events-special.caldata, would all be processed together.

These calendar files must all be in the same directory, typically /usr/local/data/www/dept.