Chronology
A custom dating system is part of a world's identity: "22 Snowbind, 1401 DR" reads nothing like "the Fifth Era, 3019". In GMTales you define your world's own Calendars and date events against them in plain prose. The shared timeline that results never leaks an event to a player who isn't meant to know about it yet.
You define one or more Calendars in Settings, date Events inside your articles, optionally set the campaign's Current Date, and read the chronology in the Calendar and Tracks views of the Articles overview.
Calendars
A Calendar is an in-world dating system: its months and one or more eras. It is campaign configuration, edited in Settings → Manage calendars rather than written in an article. Defining and editing Calendars is restricted to the Creator and game masters.
Editing a Calendar replays every Event already dated against it: change an offset, a month length, or an era anchor and the chronology moves with it. An edit that would leave an already-written date unreadable, like renaming a month that dates use, is rejected with a message naming the first date that fails, so no event ever drifts silently. Once Events reference a Calendar, its key can no longer change and the Calendar can't be deleted; re-date or remove those Events first.
Each Calendar has:
Months — a name and a fixed length in days for each. There are no leap rules.
Eras — each with a
key(e.g.DR), a display name, an anchor, and a direction. A Forward era's year numbers grow later in time (Downs Reckoning); a Backward era's grow earlier (a "Before Reckoning" count).Date format template — a single template that drives both how dates are read and how they are shown.
A typical Downs Reckoning calendar uses twelve 30-day months (Frostwane, Thawmark, Greentide, Suncrest, Highsun, Goldfall, Emberwane, Mistveil, Snowbind, Deepcold, Starfall, Yearturn), one forward era DR, and the template:
The format template and the precision ladder
The template lists placeholders in significance order. The available placeholders are {era}, {year}, {month} (the month name), {monthn} (the month number), and {day}. You write one full template; shorter dates then work automatically. Leave off the least significant parts and the date is read at that precision. With the template above, all of these are valid, at decreasing precision:
A date's precision is therefore whatever you chose to write, and it is preserved everywhere. A year-precision event is never shown with a made-up day.
A template must list placeholders in a consistent significance order, separate adjacent placeholders, use each component at most once (so {month} and {monthn} can't both appear), and include {era} if the Calendar has more than one era. Month names must be unique when {month} appears. A template that can't yield an unambiguous reading is a validation error when you save the Calendar.
A semicolon can't appear in the template, in a month name or in an era key. A written control separates its arguments with ;, so a date containing one could never be written at all: in <!-- time: 3 Frostwane; 1 5E; the forging --> the date would read as "3 Frostwane" and the description as "1 5E". Saving such a Calendar is refused with the character named.
Primary calendar and offsets
Exactly one Calendar per campaign is the primary. It fixes the shared zero-point of the campaign's timeline, and every other Calendar declares an offset in days that aligns its own epoch to the primary, so events authored against different Calendars land in the right order on one axis. The primary's offset is always 0. Your first Calendar is made primary automatically, and single-calendar campaigns never touch offsets. You promote a different Calendar rather than demoting the only one, and deleting the primary promotes the next in its place.
Dating Events
One control, time, dates everything in the chronology, and what it dates depends on how you write it. An Event is the row it produces: a dated point or span attached to the article passage it sits in. It inherits that passage's visibility; in the Calendar its description shows as plain text.
A one-liner with a description is a mention — calendar data, the temporal counterpart of an image marker. You author it inside your prose, it does not render in the article body, and it surfaces in the Calendar:
A block dates the passage it wraps. Where a one-liner is data, a block's body is prose: it renders where you wrote it, with its dates on it.
A one-liner with no description dates the article's subject — the character's life, the kingdom's existence. Write a moment, or a range with from= and to=. Either half of a range may be left out, and a bound you leave out reads as one still running.
An article has one time, so it carries one at, or one from and one to. The two halves need not be written together: put the start at the top and the end inside a secret, and only the readers of that secret learn when the subject ended. Mentions and dated passages have no such limit, though one time block can't sit inside another.
Only at and a mention's description are ever written by position. Write from, to and calendar by name, because an argument list has no way to skip a slot.
Every form:
Written | Dates | In the article | In the Calendar |
|---|---|---|---|
| a mention | nothing | a dot |
| the subject, at a moment | a chip in the header | a dot on the article's track |
| the subject, over a span | a chip in the header | a bar |
| the subject, from a date on | a chip in the header | an open bar |
| the passage it wraps | the passage, with a chip | a dot |
| the passage, over a span | the passage, with a chip | a bar under the article's own |
| a mention per entry | the banded list | a dot each |
The date is written in the chosen Calendar's own format, at whatever precision you like. A bound on a passage or on the subject needs a year or finer, because an era is a place to count from and has no last day. A mention may be as vague as the era.
A date that can't be read against its Calendar is a validation error, so a typo never silently becomes the wrong date. So is a range that ends before it starts, a mention given a range, a subject written as a moment and as a range at once, and a second bound of a kind the article already carries.
A time block won't save inside a box or a quote. Those two render their bodies without running the blocks inside them, so the passage would be dated when you saved it and then shown at every date. A secret and columns do run what they wrap, so a dated passage sits happily in either.
Which Calendar a time uses
Resolved in this order:
An explicit
calendarargument on thetimeortimelinecontrol itself.The article's default, set once at the top:
<!-- calendar: downs -->.The campaign's primary Calendar.
Calendar-bound timelines
A timeline block is free text and presentational by default. Add a calendar argument and each entry becomes a real, dated Event that joins the chronology. A calendar-bound timeline also renders like the chronology, inline where you wrote it: entries are resolved against the Calendar, sorted, and grouped into era and year bands, the same look as the Calendar itself:
A timeline without a calendar argument stays free text: no Events, rendered as a plain inline timeline in the order you wrote.
Writing a chronicle
The campaign's own story is worth an article to itself, written session by session. Give it a time block per session, and inside each block write what happened and drop a marker where the party stood. Add mentions for the beats worth a dot of their own.
The open from= at the top is your first session's date. The rest follows from the dating: the markers draw the party's trail across the map, and the article's row in Tracks is the spine of the campaign. What happened since last session is its latest passage.
Moving the Current Date stays a separate act in Settings. A chronicle records where the party got to. It doesn't move the campaign's clock.
The Current Date
A campaign has an optional in-world now, set by a game master from Settings → Manage calendars: pick a Calendar and choose an era, year, month and day. The Current Date marks where the story stands and defines which Events count as upcoming. Clear it at any time. It is the game master's clock.
On the map
A marker or region written inside a time block is dated by it. A pin written outside any time block has no dates of its own.
Where one article has several dated markers on the same picture, they draw as a trail: a line through them in date order, the latest pin solid and the earlier ones faded, each still opening its own text. Dated regions of one article draw the latest as the border and the earlier ones as faint outlines. So a map shows the movement rather than every pin at once.
The Calendar
The Calendar and Tracks are two views of the Articles overview, beside List, Index, Tree and Graph, and the filter panel narrows them the same way it narrows a list. Between them they show the chronology two ways:
The Calendar: a timeline of era and year bands, each listing its Events in order. Click a band to drill into it, and a month grid for that year places each Event on its month, and at day precision on its day.
Tracks, one row per article that carries a date, grouped by article type. The article's own time draws as a bar, the passages it dated as thinner bars beneath, and its mentions as dots, all in the author's colour. A bar whose start or end you were never told fades out to the edge of the axis rather than stopping, so an ongoing subject and one whose end is kept in a secret read the same.
A mention and a dated passage each appear once, where they happened. An article's own time appears at each of its ends, in the band it began in and again in the band it ended in; a subject dated to a single moment appears once.
Click a year's label in Tracks to read that year on its own: the axis narrows to it and the rows with nothing in it step aside. ← All years in the sidebar comes back out. The axis runs from the earliest date you were told to the latest, so it never reaches past what you can read.
The Current Date appears as a "you are here" marker, and on the timeline a per-viewer Upcoming panel lists the Events still ahead of it. In Tracks it stands as a line across the rows.
If the campaign has more than one Calendar, a selector switches which one dates are displayed in; the chronology is the same, only the reckoning changes. The Calendar is read-only and open to anyone who can read the campaign, and each viewer sees only the Events their visibility allows.
Spoiler Safety
Every date is a self-contained absolute point: no relative dates ("three days after the fall of Redwater"). A range is two of them, each written where its own readers are, so an end kept in a secret is invisible with that secret and the span simply reads as still going. A view keyed by date can therefore leave out the Events a viewer may not see without leaving a gap to infer them from, and every number it shows counts only the Events that viewer can read. A player browsing the chronology can never deduce that a secret event sits between two they can see.