The Chronian model admits as many different timelines as you care to define, but here are the few that you will probably see most often. Remember that although there are lots of different combinations which each count as a distinct "timeline" in the model, that does not mean that an implementation needs to define a class for each one.
International Atomic Time is what most of us would think of as "true physical time". (Physicists have a rather more formal definition; they can define their own timelines appropriate for their work which distinguish, for example, between proper time and coordinate time.) TAI is based on atomic clocks and basically just counts the seconds that elapse, although for convenience that number of seconds is normally expressed in YYYY-MM-DD hh:mm:ss format. The defining characteristics of TAI are that all seconds are exactly the same length (to the best of our ability to measure them, which is quite good), and that it is completely predictable (second N is always followed by second N+1, and the number of seconds in a minute or days in a month is determined by fixed, unchanging rules).
Because the rotation of the Earth is not entirely regular, TAI slowly drifts away from astronomical or solar time.
Coordinated Universal Time (the abbreviation "UTC" is not a typo; a committee was involved) is the basis for most timelines in daily use, i.e. "civil time". It differs from TAI because a leap second is occasionally added to keep it roughly syncronized with solar time. Thus it is always offset from TAI by an integral number of seconds. It is also expressed in YYYY-MM-DD hh:mm:ss format, but in UTC the seconds field has a value of "60" during leap seconds.
It must be pointed out here that "GMT" (Greenwich Mean Time) is no longer used, but many software libraries still include "gmt" in the names of their functions. If you see this, simply read it as "utc" because they're all actually returning UTC values.
Although there is only one official UTC, there are various "flavors" of closely related timelines often used in programming. Unfortunately these are often carelessly and incorrectly referred to as "UTC", but the Chronian model distinguishes between them. That doesn't mean you can't use them — as a practical matter you often must use them — but in the Chronian model you should be careful to refer to them by their correct names.
The official UTC timeline (with the current definition) started in 1972, so technically any times earlier than that need to be expressed in some other timeline. That is quite inconvenient, so we can extend the UTC timeline retroactively as far back as we like. The catch is that we don't really know what leap seconds would have been required (those are determined by observation, not by mathematics), so proleptic UTC can really only be an approximation of what UTC would have been if atomic clocks had been available to Julius Caesar or Qin Shi Huang.
There is also a bit of awkwardness during the period 1961-1971 when UTC had irregular sub-second jumps and irregularities. If you care about that, you can define (yet another) timeline to account for it. For our purposes we'll stick with the current definition where the only adjustments were whole leap seconds staring in 1972 since that makes the set of timepoints predictable in the past. Just be aware that at least the low-order bits of such proleptic UTC timepoints are really a convenient fiction.
UTC (after 1972) includes leap seconds, period. There is no debate or choice about it.
Most computer date-and-time libraries ignore this inconvenient fact and pretend that leap seconds don't exist, and they don't even all pretend in the same way. Although they claim to be using UTC, the time scale they actually use should more accurately be called "UTC without leap seconds". We can define this as another timeline, indeed we must do so to be able to interoperate with nearly any computer.
A few computers (e.g. those running the GPS system, the atomic clocks at national laboratories, or NTP servers) do include leap seconds, probably because they have to in order to function properly. These systems use UTC with leap seconds included (the official definition).
Many, perhaps most, computers cover their eyes and pretend really, really hard that leap seconds absolutely don't exist. When the NTP (network time protocol) signal comes through after a leap second and doesn't match their own clock, they behave as though their oscillator malfunctioned and "correct" their reading. This is nasty, as it's more or less unpredictable. We need to define a timeline to describe what they're doing, but the best we can really do is omit the leap second values, and when mapping true UTC values into computer time we have to map the entire leap second into the first instant of the next second, as though the physical clock on the computer had frozen for 1 second.
A few systems try to do a bit better, and the OS knows about leap seconds but smears them out across a few minutes so applications can go on blissfully ignoring them. This is at least well-defined so it's a bit easier to deal with.
Both Frozen and Smoothed UTC timelines have the same timepoint values, but the conversion functions to-and-from true UTC are different.
Next we get into offset-from-UTC times, for example Eastern Standard Time or Pacific Daylight Time. These have a fixed offset from UTC, so it's pretty straightforward to deal with them. They can be expressed unambiguously with strings like "2007‑08‑14 15:21:00‑08:00".
Of course, with an offset timeline you still have to decide whether you want proleptic and how you'll deal with leap seconds.
Finally we get to the timelines that people actually use in everyday life, i.e. "civil time". We'll call these Zoned timelines because their values and behavior are defined by the IANA zoneinfo files for timezones. For example, we can have "America/Los_Angeles" time, also known by the synonym "US/Pacific". These have rules that typically switch between a couple of Offset timelines. Zoned timelines also add the additional complication of gaps and overlaps twice a year when the offset changes. As always, you still have to make proleptic and leap-second decisions.
Please always remember that "Pacific Standard Time" is not the same as "US/Pacific" time. In the Pacific timezone, PST is in effect only in the winter; in the summer PDT is used.
This all sounds like a mess, because it is, and the Chronian model cannot fix that. When you set up a timeline you need to specify TAI-or-UTC, whether it is proleptic, how you handle leap seconds, and what the offset or IANA zonename is.
In the traditional model, the model and/or library tend to lock you into specific choices, and if that isn't what you need then you're out of luck and are forced into horrible hacks and kludges. However in the Chronian model you can precisely specify the one or few specific timelines that you need and use those correctly, so the problem at least becomes tractable. A further potential advantage of the Chronian model is that by forcing you to make explicit choices you have to think about what you really mean and are more likely to write correct code.
As a convenience library implementations may choose to provide defaults for almost everything, making the library more accessible for users who really don't have a good understanding of times and dates, but such techniques should be used with caution to avoid luring the innocent into sloppy and incorrect logic.