I’m using long events as named “periods” to map out sections of a timeline. One way to set up such a period, say “Gold Rush”, might be to define its start date to be the same as that of “Abe discovers the first gold nugget” and its end date to be the same as that of “The goldmine is closed”. When you set up such constraints, however, there’s an obvious conflict with the default duration of 0s. What I’d like is an option to resolve this conflict by changing the duration. Currently the choice seems limited to moving either of the terminal events; the duration therefore has to be set manually. Any chance of adding this, assuming I haven’t misunderstood something? Thanks.
We realise that some people would want to use constraints this way (so that the duration is changed, rather than the end date), so we are planning to look into how we can implement this to suit both needs.
1 Like
Thanks Jess. Musing on this further, I realised that - where a constraint can be satisfied by multiple adjustments - one can either resolve the issue by specifying the date (or the duration) to change, or by pinning one or both of the terminal dates/duration, thereby wittling down to a final choice. The latter may not be the best interface, but the notion of “pinning”, when applied to dates, is very appealing to me viz. making pinned events fixed points on the Calendar about which the date calculations for other events must flow. That would be really helpful when planning from the general (Tim and Charlotte stay married from 2021 to 2033) to specifics (Charlotte selects a solicitor). Are there any plans to implement something like this?
We currently have the ability to “lock” events, so that their dates don’t move, but this covers the entire event (eg. start date, duration and end date). We currently don’t have plans to change this so you can just lock part of it (like start date), but we can add it as a feature request.
Hi Jess. I’ve amended the original post to use the word “pinned” instead of “locked” so as to avoid confusion with the existing lock feature. Just to clarify, by contrast with locking, pinning a date or duration would merely insulate it from being a candidate for change when resolving a date conflict. Manual changes would still be possible without unpinning. Also the idea is that pinning elements (start date, end date or duration) would not only prevent a fully automatic change but could also be the way to select what element to change when clicking “Resolve”. I’d appreciate this being added as a feature request. Thanks.
Hello, I’ve also run into this (or maybe a similar?) issue and am wondering if there’s a fix in the works? I essentially tried to assign a character’s birth and death date. Due to the duration of 0s, it automatically assigns that as the character’s death date as well.
Setting the birth date and then a constraint to set their death at an event already on the timeline overwrites the birth date with their death date because the duration is 0s.
I am unable to modify the death date, only the duration…so I have to calculate how long the character lived to get to the exact date and time of their death. That’s a huge time sink when I’ve multiple characters to get into the timeline.
No there currently isn’t work being done on this, although it is still something we plan to look at in the future.
However you should still be able to manually assign a character’s death date in the Inspector, which would adjust the duration. Is this not happening for you?
No, that does not happen. That’s what I expected to happen, though.
Manually assigning the character’s death date with the duration set to 0s just results in the character’s previously entered birth date getting reset to the death date I just entered. But I can’t delete the duration and just let it recalculate, either. My work-around has been to set an event called “Bob’s death” for example, and then setting that date and locking it. Then I have to use the constraints function to set Bob’s end date to the end of the event “Bob’s death” and then resolve.
Is there some kind of setting I need to adjust so this stops happening?
No there isn’t a setting that moves the start date in this instance instead of altering the duration.
Just to clarify, are you having this problem on character’s that do not have any constraints assigned to them? Having constraints on the character would show the behaviour that you are seeing, which is related to the feature request in the original thread.
However if they don’t have any constraints, then you should be able to adjust the death date in the inspector without the start date moving. If this is happening on character’s without constraints, are you able to send through your timeline to support@timeline.app ? This would help us replicate what you are seeing and work out what is going on.
Hi, thanks for the response. Honestly, I can’t remember if maybe they might have had some other constraints on them. I started a fresh file to see if I could figure out what’s happening.
-
Entering a birth date and then a death date will make it calculate a duration (expected result)
-
Altering the birth date results in a recalculation of the death date, and the duration is unchanged. The date of death is changed to match the duration (unexpected result; I contend most people aren’t calculating the exact amount of time their character is supposed to live. The default should be that the duration should be recalculated, not the date of death)
-
Altering the death date will make it recalculate the duration, while the birth date remains unchanged (expected result)
-
Deleting the duration to try to make it stop recalculating the death date results in setting the duration to 0s. The death date is reset to match the birth date (unexpected result). However, now re-entering the death date will result in the proper calculation of the duration.
-
Assigning a death date before the birth date results in the death date being entered as the birth date, due to default duration of 0s (unexpected result)
-
Assigning a birth date to that person results in the death date being overwritten by the birth date, again due to the default duration of 0s (unexpected result). But re-entering the death date now results in the proper calculation of duration.
Hope that’s helpful. There’s not really anything in the file, and I’m a new user (to this version, previously used your 2nd iteration) so basically it’s the latest version of your timeline. I also sync with Scrivener, which I’ve been using various versions of since 2013. The only change I made to settings was to create a third era (era 1, BC, unchanged; era 2 set to 10,000 years; era 3, infinite, unchanged).
It seems to be the duration setting that’s the root of the problem. Yes, it’s workable by entering and reentering things in a different sequence, but it shouldn’t require that much thought. As for my main file’s problems, I’ll see if I run across the problem again–I’m finished entering most of the characters at this point, and I think part of the problem is how many of them there are and how many interactions there are with different events. Maybe an issue with some of that already being in place before they get assigned their birth and death dates? Will return here to let you know if I figure it out.
Thanks for adding such a detailed response.
The examples that you sent through that caused unexpected results from what you are expected can be changed with a setting. If you open Timeline Settings (the cog icon) and choose “Disable auto-adjustment” from the Automatic Date Adjustment menu, this will then mean that when you change the Start Date, the Duration will be recalculated, not the End Date. This is not the default setting, which is why you see the opposite on a new file.
The only thing that would still cause unexpected result to you is assigning a death date before a birth date. This is currently not allowed, so it will default to the end date that matches the current duration.
However version 2 would always adjust the end date when the start date was adjusted, so I’m not sure why this behaviour would seem different from that version.