Brainstorming multiple calendars

Feature Requests
#30

This made me laugh. Somehow, I hadn’t thought about warp drive from this perspective. In looking it up, I see it began as a narrative device, not as a scientific idea. Talk about writing your way around a problem!

So, from the perspective of AT, the linear timeline restraints on the proposed multiple timelines can remain for many (most?) authors and still represent a massive step forward for the software. Those who want to write stories where something like warp drive isn’t available can always do manual calculations sufficient to fix the event on differing timelines (much as sci-fi authors do now, anyway).

#31

Okay, I’ve abandoned all hope of writing my scene this morning.

Have you been following this guy? He’s on a five-year mission to build a 40-foot model of the original Starship Enterprise. https://youtu.be/kdDXeIpphZA?si=XrrO0pmGrHlf_fBm

:rofl:

#32

But seriously…I do think this discussion offers some solid and practical ideas for the AT development team to offer multiple timelines. There are a whole lot of folks who would like to see such a feature, that’s for sure.

#33

I’d say the practical benefit to the SF writer is the realization that you have to invent a system that either negates the relativistic issues through “technological progress” (Star Trek), or simply ignores them (Star Wars).
By the way, when I was drawing comics once, I came across a very useful guide on the web: “Perspective – how to avoid it”.

2 Likes
#34

Yesterday I must have strayed a little from the actual topic. In the meantime, as I also write SF myself, I have given some thought to the question of multiple calendars. What is the benefit for a writer anyway?

If the story is to take place on several worlds, the local season and time of day can be of decisive importance, as they can influence the plot via the environmental conditions.

Independently of this, the question of general narrative time progression can be considered, e.g. in order to maintain an overview of the chronology and of cause and effect in non-linear narration. This would require a “standard time” that applies everywhere.

First, I ask myself about the leading view, i.e. which of the calendars in question has the greatest influence on my work? Do I need to pay close attention to how the local conditions in the narrative world are changing? Do I need to coordinate events that take place in different “time zones”? Do I have flashbacks that need to be visible on a timeline? Are there historical time references that should be precisely documented, or will a few notes suffice?

I’ll assume that these are important questions that I want to use AT as a tool to clarify. I have also come to understand that the majority of users do not want a workaround, and certainly do not want to go down the path of external calculations and scripting. In addition, the timeline is linked to the plot structure of the narrative in AT3, which makes the maintenance of several timeline projects for one writing project seem inadequate.

All this would certainly suggest that the developers are looking into this question.

1 Like
#35

Let’s hope. :slight_smile:

#36

Incidentally, a long-known problem concerns the time zones, a kind of simplified special case of our topic, so you could say. As far as I know, Aeon Timeline does not yet have a solution for this.

#37

So, if something like what we’ve been kicking around were created, this would be straightforward, if not trivial. One calendar would be in one time zone, and another in another. Once the display ratio is established, the author could scroll both timelines and see where a given event would be on the opposite timeline.

I suppose a more difficult problem would be the shift to daylight savings time and back to standard time, in those locations that practice that. As a practical matter, a separate timeline could be made for each such period–it certainly would be more reasonable to expect the user to do this than for the development team to build in some sort of time shifting capability.

#38

There would be a simpler solution for the time zones with daylight saving time, which is probably also implemented in the operating system: The internal timestamp could be UTC, while for the time scale and events you can select the time zone for display at any time in the current session. However, the technical catch is that this creates a special case in the system of generally definable calendars.

1 Like
#39

Ok, compared to the discussions here, my problem now seems a bit trivial!

I have a society that has stratified into a “commons” and a “nobility” (not uncommon, after all). The commons use different names for the same time periods (like days) than the nobility. Is there an easy way to use different names for the same time?

Also, is there a way to rename the units themselves? e.g., a day is a cycle, a week is a span, etc.

Thanks

#40

When setting up your calendar, you can specify names as well as short names for your months and weekdays. Maybe this is a way to reach your goal?

Translating the user interface might be the way to go. See:

1 Like
#41

I tried this, but it doesn’t really work for me. I’d like to be able to have dates in both “languages” so to speak. Perhaps the localization practices below might work? I’ll have to experiment with them. Thanks for taking the time to reply, though!

#42

I see. I found a simple solution with AT2. I think it would also work with AT3:

months

weekdays

event
event704×252 11.8 KB

#43

And I think I need to drag all of you back to Earth, just for a few minutes… :rofl: :rofl:

The Problem with Artificially Set Epochs in the Digital World

Different computer systems use different epoch dates as their reference points for time calculations, and even within a single ecosystem, there can be inconsistencies. For example:

  • Windows uses January 1, 1601 as its epoch.
  • MacOS uses January 1, 1904.
  • Excel, despite running on Windows, follows Unix time, meaning it starts from January 1, 1970.

This inconsistency creates significant problems, especially when dealing with historical dates. Events that occurred before these artificially set epoch dates must be represented with negative time values, but each system treats these differently—causing inconsistencies when mapping data across different platforms.

Impact on Historical Research

  • Loss of Accuracy: Since historical dates must be stored as negative values, discrepancies arise depending on which epoch each system uses. This can affect historical analysis, data comparisons, and event tracking.
  • Lack of Support for Negative Dates: Some systems do not support negative timestamps, meaning pre-epoch dates cannot be recorded correctly without complicated workarounds.
  • Data Compatibility Issues: When transferring historical data between systems that use different epoch dates, errors can occur, leading to misalignment of dates or outright data corruption.

These challenges mean that anyone needing to work with dates preceding these artificial epoch points will likely encounter difficulties in maintaining accuracy and consistency.

1 Like
#44

I think I will “drag” you all down to Earth again for a few minutes, some of this I already mentioned in the earlier comment, but I took the liberty to get som AI help, since I am not a native English language user, to address these problems a little more technically:

Addressing the Limitations of Artificial Epochs and Multi-Calendar Support in Aeon Timeline

A significant challenge in handling historical and multi-calendar events in software like Aeon Timeline arises from the way modern digital systems define fixed epoch points for time calculations. Different operating systems use different artificial zero points, which leads to inconsistencies:

  • Windows: Epoch starts at January 1, 1601
  • MacOS: Epoch starts at January 1, 1904
  • Unix/Linux/POSIX: Epoch starts at January 1, 1970
  • Excel, despite running on Windows, follows Unix time (1970)

These discrepancies introduce problems when dealing with historical events predating these epochs, as many systems do not support negative timestamps, making it difficult to record dates before these artificial reference points.

Why This Is Problematic for Historical and Multi-Calendar Timelines

  1. Loss of Accuracy for Historical Events Since historical dates must be stored as negative values, inconsistencies arise when trying to align different epochs. This affects historical analysis, event tracking, and cross-system data sharing.
  2. Limited Support for Non-Gregorian Calendars Many systems are built around the Gregorian calendar, which does not account for Julian, Hijri, Chinese, or other timekeeping systems. This makes integration with multi-calendar datasets difficult.
  3. System Incompatibilities with Historical Dates Certain applications (like Excel) may fail to process pre-1970 dates correctly, leading to errors when exporting or working with datasets across different platforms.

A More Robust Approach: Floating-Point Time Model with Dynamic Epochs

A more effective solution for Aeon Timeline and similar systems would be to implement:

  • Floating-point time values instead of integer-based timestamps, allowing high-precision handling of both past and future events.
  • Dynamic epoch selection, where users can set their own reference date, making it possible to work with multiple calendar systems fluidly.
  • Multi-calendar support, allowing events to be displayed across different timekeeping conventions without losing accuracy.

The Need for Metadata in Exported Data

For such a system to be functional outside the original software, exported data must include essential metadata:

  • Defined epoch reference (the chosen zero-point for time calculations).
  • Calendar system definitions, including rules for converting dates across different systems.
  • Algorithm for multi-calendar period calculations, ensuring historical, contemporary, and future dates are consistently mapped across all relevant time systems.
  • Cross-calendar reference points, linking each calendar to at least one universally recognized timekeeping standard to ensure correct alignment between them.

This approach would improve data portability, historical precision, and multi-calendar integration, making timeline management more versatile across disciplines like historical research, fiction writing, and scientific chronology.

Furthermore, this approach would allow for multi-dimensional time representations, expanding beyond simple linear timelines. By incorporating a floating-point time model, one could define three- or four-dimensional time structures, enabling alternative ways to track and calculate temporal events. For instance, separate dimensions could represent parallel timelines, relative time dilation effects, or nonlinear chronological sequences that adjust dynamically based on predefined parameters. Additionally, it would be possible to create custom algorithms for unique time units, periods, or cycles—including dynamic, non-linear timeframes where intervals may vary based on specific conditions or events. This would be especially beneficial for applications requiring custom calendar systems, fictional time mechanics, or advanced scientific simulations.

Note: This comment was translated and transcribed from Norwegian into English with assistance from Microsoft Copilot, who also helped refine the text for clarity and fact-checked the claims presented. :blush:

1 Like
#45

Is this made up by the “Copilot”? Actually, floating point calculation is definitely not an option here, as it fails when adding very small values to very large values. What is needed here is truly a fixed basic unit such as a second, and a bit width that covers the entire integer value range.

I have recently been looking more closely at the calendar representation of the .aeon file format. It hasn’t changed since AT2, and is based on a timestamp that apparently counts forward in seconds from the beginning of the last era, and continuously backwards for all previous eras. It’s not pretty to calculate, but I don’t see a problem with accuracy at first.

#46

No, it was simply translated and refined (I asked it to format the text in a readable way instead of just one long writing as I started with) for clarity in English from Norwegian by Copilot. It did help me with some terminology, such as “Epoch Points,” since I wasn’t familiar with the correct term in English.

The idea of using floating point was mine, as a way to handle multiple calendars with better possibilities for calculating asynchronous time periods, using algorithms to create non-linear calendars, and incorporating “crossover dates” or common/shared epoch points.

I understand that floating point can have issues with extremely small numbers, but how often does anyone actually need to work with a time value as small as 10⁻¹⁵?

Of course, if extreme precision is required, arbitrary precision arithmetic would likely be a better choice.

The main issue with today’s system calendars is that most of them do not support negative numbers/dates, which are necessary for historical dates. If all system calendars used a common epoch point and supported negative timestamps, this problem might be reduced.

Today’s ISO standard will work for most “normal” calendars, but it is not well-suited for non-standard, non-linear calendars—especially those that are not based on seconds, or those that follow cyclical or event-driven timekeeping instead of continuous linear progression.

I apologize for using floating point as an example instead of arbitrary precision arithmetic—it was simply the first thing that came to mind. I’m neither a scientist nor a programmer, just someone thinking logically about the topic.

Of course, it might be better to use “arbitrary precision arithmetic” if you work with something that need extreme precision…

The problem with today’s system calendars is that most of them doesn’t support negativ numbers/dates, that is needed for historical dates, if all system calendars used a common epoch point, and if they all supported negative dates, it might not be a problem…

Today’s ISO standard will work for most “normal” calendars, but it will not work well for none-standard none-linear calendars.

Sorry for using floating point as an example insted of for example arbitrary precision arithmetic…
I am neither a scientist nor a programmer, I only write or talk based on my own logical thinking, and floating point was what fell into minded when I wrote this.

NOTE: This text has been translated and refined by Copilot from Norwegian to English. It also helped me find the correct terminology, such as “arbitrary precision arithmetic,” since I wasn’t familiar with the correct term in English. In Norwegian, I would have used something like “ekstremt store positive og negative tall med høy presisjon”, or "astronomisk høye positive og negative tallrekker med ekstrem presisjon."

#47

That’s something else, of course. The idea is to make arithmetic operations not dependent on the word width of the hardware processor registers, but to execute them using software algorithms that process any number of digits. I imagine this to be similar to division on paper with carry-overs and remainders, where you can theoretically process any number of digits. This would allow you to map events back to the Big Bang with seconds of precision, but would require a little patience on the part of the user (and big files filled with all those numbers).

Perhaps the problem areas should be named more clearly and distinguished from one another. As a developer of timeline software, you undoubtedly have to restrict yourself to a limited range of use cases in order to come up with something practicable.

As far as I can see, the ISO standard has no relevance in AT, especially as it is not suitable for the “BC” era and certainly not for user-defined fantasy calendars.

But what exactly do you mean with “Epoch points?” If you use the same wording as Aeon Timeline, you probably don’t need the assistance of a LLM, do you?

#48

I addressed these issues in my original comment where I used floating points as an example. You were not satisfied with that, so I included arbitrary precision arithmetic as an alternative to clarify the point.

I have no idea what terminology is used by either novelists writing fantasy fiction or Aeon Timeline, nor do I have any particular interest in familiarizing myself with it, as fantasy novels or other long-format fantasy writing are not within my area of interest.

I tried to address this on a more general level, where historical calendars and other calendar formats could be used with common time instances as reference points to synchronize multi-calendar functions via those points. Since the digital world specifically uses Epoch time as a zero-point reference for time, I used that terminology in my text.

If you don’t know what Epoch Points are, here is a good explanation: EPOCH Definition & Meaning - Merriam-Webster

In this specific case, I am using it as explained in point 3.

I have no real interest in continuing this increasingly detail-focused discussion, as I have already stated my viewpoint and thoughts on the topic.
I am fairly certain that this will never be addressed by the developers of Aeon, and what others do with their workarounds doesn’t really matter in this context, because it doesn’t affect my use of the software—whether it supports a million different non-linear fantasy calendars or not.

#49

In this sense, the epoch for AT2 (and I assume that this also applies to AT3) begins on the first day of the last era, and can therefore be influenced by the user, even if not in an ideal way.

Your latest posts made me curious, and I wanted to find out to what extent the concept of the epoch of the Aeon Timeline software affects the accuracy in practice.

  • The leap year count always seems to start on the first day of each era with leap years. Depending on the beginning of the last era, the leap year count can become discontinuous.
  • Even worse, counting backwards affects the days of the week of the previous era. For example, I have set up a calendar in which the “AD” era is followed by an additional user-defined era. “AD” now lasts 2025 years, and its first day, 1.1.001 is no longer a Monday, but a Friday. This shifts all weekdays of the first two eras.

However, this seems to me to be off-topic, as it is not about the realization of multiple calendars, but about a fundamental problem with the implementation of the time calculation for multiple eras.
See also on this topic: Eras and weekdays