Changed times in $StartDate

Q & A - getting started with Tinderbox
1

Hi, happy new year everybody. I am having an issue with the $StartDate and $EndDate attributes, which I’m using to assign dates to an event for a historical chronology. I’ve just noticed that when I also assign a time to the event. eg 25 Dec 1980 at 23:50:00, the time (and so presumably the date) is contingent on the time zone I was in when I created or last edited the note.

Change timezone, and the times (and presumably dates) change accordingly. For obvious reasons this isn’t what I’m looking to do, but I understand why it might do that.

There’s presumably a way around this in some way, but a) I can’t figure this out – a location attribute? and b) I’m hoping there’s a way to do this without too much rolling backwards.

Any help would be much appreciated.

2

I just tried this an I could not reproduce it. What do you mean “Change timezone?” What steps are you taking to reproduce this?

3

If i close the file, change the timezone in macOS system settings, reopen file, the StartDate will interpret the StartDate in the new timezone (in my case, from Singapore to UK timezone, pushing the events eight hours back)

4

I see the point, but I don’t believe there is a time-zone ignoring flag for Date-type attributes. Indeed there isn’t a one-size-fits-all answers. I can see that for what we might term ‘historical’ dates, current time zone is immaterial and a time-zone shifting that shifts a date into the previous/next calendar day is a decidedly poor result. Conversely, if working in the present on a do do list time might need to shift according to locale.

Having noted that, were such a toggle to be added, I’d vote for the default to be to not respect the system time zone and have the non-default toggle to be for where the current time adjustment is carried out. I could imagine an extra tick-box on the system/user panes of the Document Inspector for Date-type attributes with an unticked box with the label “honor time zone”. If ticked the app adjusts the actual date/time displayed for the current time zone (i.e. as currently happens) as opposed showing to the ‘raw’ stored date-time with no further adjustment.

I can see it’s an edge case as not make of us make timezone change often. As summer time—for polities that have it—is an hour only times from 23:00 through to 01:00 are potentially affected in terms of time change altering the calendar day of the date.

For now, pending any possible changes to the app, I don’t think there is a fix other than not adjusting your system clock. In System Attributes:

Date & Time 2023-01-01 13-37-07
Date & Time 2023-01-01 13-37-071336×1210 127 KB

For short trip abroad I normal turn this off (as other apps besides Tinderbox are affected by this). Clearly the each OS update resets the default (ticked). Ugh.

HTH

5

Thanks @mwra, I did suspect this might be the answer.

As I am permanently relocated – and have been blithely adding new entries for a few months not noticing the error – this is something of a setback. Most entries aren’t hour-specific, but even then the jump in timezone is now explaining why I seemed to be entering so many entries incorrectly.

I guess for now the next best steps are

  • to move all the last six months’ worth of stuff so they’re aligned with the former timezone and
  • then set a stamp to add the correct date/time as text to the title of each note (replacing the current with $StartDate.format("y || M0-D | t")+" : "+$Name;)

I’m not sure how I would go about the second point, but I’ll start fiddling around. Any guidance would be very welcome.

6

In Ventura the system settings look like this:

Screenshot 2023-01-01 at 11.46.47 PM
Screenshot 2023-01-01 at 11.46.47 PM1402×756 80.1 KB

For previous discussion on this and @eastgate’s gratifyingly succinct description of current behavior see:

I tend to think of it, I hope correctly, as Tinderbox storing a particular point in time as an ISO date-time string. That point in time should not change after switching to another time zone and then back again.

I wonder how many historical dates seem “off” by 1 day depending on where one is located on Earth.

7

Although stored in the XML as an ISO date/time string, within the app Date-type date is treated as a millisecond offset from the unix epoch. IOW, date-time ‘arithmetic’ is maths done on numbers of milliseconds which are then parsed back to the UI in human-understandable date-times.

Also, a side-effect of the above is regardless of how rendered, there is no notion a a time-less date, IOW a date scoped to day at minimum. Time might seem immaterial, but even if working in years, we might want to know Jean D’Arc age at death based on knowing the year (portion) of the date(-time)s of her birth and death. Dates stored as strings needs to be turned into a number for that sort of maths, so dates-as-strings help … until they don’t. Again, there is no one-size-fits-all answer.

Plus if we do translate from string storage to number for a day-scoped date, where to we set the time that arises (noting date-time maths is in milliseconds). My best guess is midday (12:00:00) which lessens the chance of off-by-one destructive effects of timezone modification of date times.

Time … is more complex than we allow for. As stated above, for ‘historical’ dates we don’t generally want to have time adjustments. But computers weren’t designed by historians (or non–engineers) and so there is no clean delimitation of fixed (zone-agnostic) vs fluid (zone-observant dates).

A kludge for now is to set the day of the date as a string or number at creation, and had an edict or stamp (rule is overkill) to check if the stored day number is the Date.day number of the date-type attribute. If note, reset the Date-type day.

As Date.day returns a number, we’ll store a new $StartDate’s day and $StartNumber. Now the code can check:

if($StartDate.day != $StartNumber){ $DateDate.day = $StartNumber;}

Of course for each Date-type attribute *$StartDate, $EndDate, etc.) in use you’d need a corresponding Number-type user attribute . Let’s assume for the moment were are only using $StartDate and $EndDate and have made $StartNumber and $EndNumber. Then you could make a stamp for new notes to use once start/end dates are set:

$StartNumber = $StartDate.day;
$EndNumber = $EndDate.day;

But, as for pre-existing date munged by time offsets, I suspect that is a case of review that is pretty manual.

8

Thanks @sumnerg, for drawing my attention to the post. It sounds as if the ‘new’ behaviour will alter date and time of notes according to the time zone the document was last saved in, which appears to be my experience.

And to your musings about how many historical dates will seem off, I was taught to be very cautious about time zones when researching international events, it’s a good point. Unfortunately in Tinderbox I’m beginning to realise just how many notes are affected. Looking at entries pre-timezone change, I can’t see a clear pattern in the hour assigned to a date by default. In fact all entries will have to be checked manually as they will all be suspect, a daunting prospect at this stage.

9

If you simple set day month an year, the time element (hh:mm:ss) of the date-time is the current OS system time. So, here in UK, as I write this it is 19:46:45 and so if I set $StartDate to the current date, i.e. “01/01/2023” the actual date-time stored is “1 January 2023 19:46:45”.

One other protective measure you can take is to extend the stamp above to:

$StartDate.hour = 12;
$StartDate.minute = 0;
$StartDate.second = 0;
$EndDate.hour = 12;
$EndDate.minute = 0;
$EndDate.second = 0;
$StartNumber = $StartDate.day;
$EndNumber = $EndDate.day;

Now your start and end dates are set to a time element of “12:00:00” (hh:mm:ss).

10

Thanks, @mwra, for your thoughts, much appreciated.

11

You might also consider creating a user-generated attribute for the timezone.

Or, create a string attribute to hold these data. When you want to do analysis on them, e.g., use a timeline, you can simple use action code to copy the value into a data attribute. Having the value in a string will ensure they won’t b messed with.

12

It’s confusing, I think, to describe or think of Tinderbox as somehow “altering” or “messing with” date-time values or having “destructive” effects. I don’t think Tinderbox does that (any more).

A date-time value, whether expressed in ISO date-time string or as a millisecond offset, is a point in time. That point in time is expressed differently depending on what timezone offset from UTC (that offset can be seen in a ISO date-time string) one wants to choose (or have the app assume) for the input and/or the display. But it’s still “just” the same point in time. The value is not altered.

Calculations can be used (shifting zones if appropriate) to express a point in time in whatever particular form suits the current purpose.

13

I take your point. Whilst not intentional, assuming all dates—or rather, date-times—are in the present or near future where the locale of the author or the event may matter (e.g. a trans-Pacific zoom call the next day). This matter having been raised, I’m struck by the thought that, overwhelmingly, zone-adjusted rendering is actually not helpful except near to the present.

That’s not so if the UI, where most users see/understand their data, shows a date that is wrong. Flying halfway round the globe, the Ideas of March in Ancient Rome (15th March) stored in a Date-attribute should remain so after flying to France or Brazil and not become the 14th or 16th day of that month simply due to the whims of present day time administration.

But, I’m not here for argument but rather to tease out the edges of these two incompatible use cases for dates & time zones. Both, in context are, necessary and correct.

Another solution here might be to not apply time zone corrections for dates over one (six?) month previous to the current date. I still prefer time-zone adjustment to be an opt-in (i.e. default: no adjustment) for Date-type attributes, set per attribute. I think the latter lets both use cases live together more easily as doubtless some will need one behaviour as much as others will need the alternative.

14

Yes, I think my main point is to avoid confusing language that might suggest that Tinderbox is not doing the right thing. All of this is already confusing enough! Tinderbox no longer “alters” or “messes with” date-time values, each of which represents a point in time that can be expressed in different ways depending on the time zone one chooses to express it in.

Calculating how to express the same date-time value in different time zones can get confusing. So I’m happy the app together with the os already take care of that by default.

Preventing time zone adjustment for historical dates, on the other hand, is straightforward. It’s simply a matter of “freezing” the day. Extract the day using the day() function and store that separately. (And do the same for time if that’s important). Then, when needing to sort or plot or perform date arithmetic, reconstruct the date using the date() function with the extracted day as one of the inputs. That is an approach commonly used in spreadsheet apps. Isn’t it already easily done in Tinderbox too?

15

It can be done, but it’s the sort of unnecessary bureaucracy that puts off many user and things that make users complain the app is ‘hard to use’ are often a foreshadowing of missing affordances. IOW, the user doing extra make-work to achieve an end that should work without it.

Time zones are a modern invention from the 1870s, leading to the International Meridian Conference in 1884 which formalised the Greenwich Meridien and the 24 time zones around the globe. Thus arguably applying a time zone correction to a date pre-1884 is both likely unhelpful and historically inaccurate. :slight_smile: The real issue is time zones don’t matter is the user never travels (with their Mac) to other time zones - at least not one more than an hour or so away. But the OP’s point shows that is an unsafe assumption.

Just like human names, date-times are complex there there isn’t a single ‘right way’. So, whilst the app is acting as advertised, it is—for past dates—not doing so in a manner helpful to the user for the reason already related.

This has been useful to kick around as I think I can now add some useful notes to aTbRef. At worst they can point people to 9a) the problem (if such there is) and (b) possible ameliorations. Anything more requires actual changes to the app.

16

Yes, date-time is troublesome and confusing. “Freezing” the day component of a date is extra bureaucracy. But, when needed, perhaps less troublesome and confusing than the alternatives.

I understand, even after the Greenwich Meridian was adopted, that the French kept expressing time in their own way for a number of years. And didn’t some former parts of the British Empire insist on an extra half-hour offset. Complicated!

Curious fact: modern China imposes one time zone on its vast territory. Extending CST, also known as Beijing Time, to the whole world would simplify matters, wouldn’t it? Well, at least for current dates. Historical dates for the previous empires that controlled all or parts of the heartland would probably remain a nightmare.

17

Yes, they had suggested a more French-centic location for the meridian … in Paris, quelle surprise! So a bit miffed, I guess. The meridian had to go somewhere and the erstwhile British Empire and pre-eminent trade/maritime status probably played a part. Thus too, I think GMT is considered non-politically correct and is deprecated for UTC. Or simply: for the confused UTC is the new trendy name for GTM (time zone offset 0).

Also of note, I think it was only in the 1950s that PRC (China) signed up to the international system placing our planet on a common global set of time codes for the first time in its existence.

More controversial seem ts to be Summer time which affect distance from the equator (latitude) rather than longitude as reflected in the 24-hr global time zones.

Written from just West of the Meridian, this day, 13 Nivôse, CCXXXI (Ardoise)†. :slight_smile:

†. via: French Republican Calendar. Or there’s always the Mayan calendar for those taking a longer term view from today (whose Long Count date is: 13.0.10.3.4).

1 Like
18

In the US between 1920 and 1940 it is hard to tell if a state used summer time. Starting with 1967 a tax law regulated the summer time in the US. In 1965 only Iowa showed 23 different start/end dates for the summer time. Until the end of the 19th century, every place had its own time, which was based on the position of the sun. A standardization of time was first sought in 1884, when the division of the world into 24 time zones was decided in Washington DC. The old rule of thumb “Noon is when the sun is at its highest point” doesn’t fit to the concept of a synchronised time - and so it was not easy to convict the people to this concept - still is…

So for a historic date it will get complicated if we try to get an absolute dating.
If you enter the $StarDate and $EndDate you are entering relativ dating parameters - and what TB did is what I would expect if you change the timezone of your Mac - the dates get converted to another timezone (internal time is still the same if you refer to UTC). It would be a nice option to set those attributes to “fixed”.

I would go with custom attributes to store your historical dates. You still could use a script to calculate the $StarDate from your attributes if you need the time there too.

I encountered a similar problem while working with GPS data. I used a good GPS lib for the math formulas. Worked perfectly east of 0° longitude. It just didn’t work west of the Greenwich meridian. The library had issued an incorrect accidental. Instead of minus, plus was used. Then I wrote to the developer and got an answer: the USA is such a great country, he doesn’t want to use negative numbers there…

4 Likes
19

For the life of me, I can’t find anything… but does anyone know if there are any logs that show when the time was changed?

20

Tinderbox Date-data-type is always a date-time. There is no discrete tracking of the time element, though you can use time(), for instance, to get hh:mm time element of $StartDate:

$MyString = time($StartDate);

$Modified (a read-only Date-type system attribute) originally just tracked changes to $Name and $Text of a note but for many years now also respond to changes to a note’s Displayed Attributes or manual attribute value edits via Get Info/attributes, or the Quickstamp Inspector. Internal changes for other reasons, including action code running automaticallly, does not affect $Modified.

But, stepping back a bit, what is the context of needing to know the change in the time element pf $StartDate as this may help us give you a better answer. For instance is it time changes specifically, or any change to $StartDate’s value such as a change that doesn’t alter the calendar day?