Adding time--hours and minutes--to a data?

I can’t figure out how to add time to date. I have minutes, e.g. 3:59, and want to add 8 hours and then add this to date. How?

Use the .hour operator for Date-type data, e.g.

$StartDate.hour = ($StartDate.hour + 8);

Sets the $StartDate to 8 hours later and, yes, if the summed hour is >24 the day rolls over (same reerse if subtracting time.

Similar operators mean can do the same to alter the year/month/day/hour/minute/second element of a Date discretely.

I got the add hour part, what is not working for me is the + $Timestamp part, i.e., and internal with minutes and seconds. I tried $StartDate="7/21/22"+(8 hours)+$Timestamp+(" minutes");+(" minutes"); and it did not work. $Timestamp, e.g., equals 00:15 to 01:30, or 01:05:12.

OK, different question to the original! So, our starting example is this:

$StartDate="7/21/22"+(8 hours)+$Timestamp+(" minutes");+(" minutes");

Several issue I see immediately:

  • the +(" minutes"); is repeated twice, that _might confuse the parser.
  • by +(8 hours) I assume you meant +("8 hours"), that _might confuse the parser.
  • setting a Date-type attribute to a string with a date format should work but the recommended format is to wrap the string is a date() operator.

Taking the last two together I think what you perhaps ought to have used is:

$StartDate=date("7/21/22"+"8 hours"+($Timestamp+" minutes"));

except you don’t say what data type $TimeStamp is: String, or Interval. Let’s assume it is Interval type, in which case 00;15 implies zero hours and 15 minutes. The default Interval value (as seen in Displayed Attributes & Get Info) uses “00:00” representing hours:minutes.

If using Intervals, I think what you want is:

$StartDate=date("7/21/22"+"8 hours"+$Timestamp);

If $StartDate is 28 July 2022 at 20:00:00, this seems to work:

Why does this work? Tinderbox figures out that it has, inside the date() operator parentheses, :

  1. a date type object
  2. an date/time increment (+ join). I used a string attribute in place of your literal string but both work the same way.
  3. a interval - a date/time data object

So it issues Tinderbox date/time arithmetic and passes the result as Date-type date ready to either set a Date type attribute or to coerce into a string, as in the above screen grab (where it is passed to text). The result illustrated is correct for most of the world except the US which reverses day and month and where the result is something like “Jul 28, 2022 at 12:01:26”. Note: the exact string formulation of the latterreflect both your macOS locale and any date format modifications therein. If you want control over format for deliberate date-to-text coercion set Date.format()

If you want to subtract literal string values, either use a minus (-) instead of a plus (+) preceding join or start the string with a minus. Intervals automaticcally pass their positive/negative state> These thus give the same output:

$StartDate=date("7/21/22"+"-8 hours"); // more flexible usage!
$StartDate=date("7/21/22"-"8 hours");

Does that help?

Do we need more/better documentation of date ‘arithmetic’ in action code? If so I’m open to suggestions. Specifically, I don’t mean demos, but rather annotated code examples like above to be added to aTbRef.

†. The exact range of the Interval type was—checks latest available Notes.tbx, as at 16 Apr 22—never formally documented. User testing suggests the largest unit is days and the smallest unit is seconds. By implication, an interval cannot be less 1 second (or is is essentially “00:00”, i.e. zero/never). Although year units are not supported, it is isn’t clear is day values >365 are allowed and if they are whether that is intentional. If a hh:mm value of >24 hours is added, this is not displayed a with ‘d’ (day) element. So if “30:30” is entered in an Interval’s Displayed Attributes value box, it displays as “30:30” not “1d 06:30”. A confusing UX behaviour. @eastgate can perhaps clarify (and I’ll annotate aTbref accordingly)

1 Like

Thanks, I’ve tried many variations to no avail. Just tried this: $StartDate=date("7/21/22"+"8 hours"+$Timestamp);, does not work.

Also, I tried to create your example, also does not seem to work:

Finally, when you paste ‘Jul 21, 2022 at 00:00:15’ into StartDate the seconds’ display is not shown. I seem to remember that there is a fix for this.

Sorry, but I"m still confused.
.

Displayed Attributes date formats are set normally via Document Settings’ Text tab but if the three choices offered don’t cover your need (e.g. none show seconds), then use the Document Inspector’s system tab to set the default $DisplayedAttributesDateFormat to the desired string.

Edit: not quite true see later below

Note: the latter sets the attribute for all notes in the document. As with any attribute, you can instead set it at prototype or individual note level. However note this is the formatting of all Date-type attributes in the (note’s) Displayed Attributes table. You cannot set a custom format for an individual attribute in the table. Exporting/coercing to text, you of course have all the format() and .format() operators at your disposal.

Meanwhile, to save going round incircles, can you post a document with the problem and a note explaining what we see as outcome as opposed to what you expect? The fact my previous long answer didn’t suffice suggests there are as-yet un-described facets to your problem. Forget the bigger context (I imagine their is one) that may affect how input value are created. all we need is a simple test doc that presents accurately the literal inputs and attribute data types involved and with real world values in them.

HTH.

Sorry for the confusion. The problem with undocumented processes are the inevitable edge cases, as here. This fails to set the right date (US users need to reverse day and month in the date string):

$StartDate=date("21/07/22 00:00"+"8 hours"+$Timestamp);

but this two-step process works:

$StartDate=date("21/07/22 00:00");
$StartDate=date($StartDate+"8 hours"+$Timestamp);

I think the edge case here (looking back at earlier tests above) is the one-step process fails if the date attribute—here $StartDate—is not set to a non-default value before attempting to alter the date. Thus this code fails if $StartDate is “never” but works if any other value:

$StartDate=date("21/07/22 00:00"+"8 hours"+$Timestamp);

After the fact, I sort of see the logic but even so i’m not sure if this is by design, a bug, or simply—and more likely—an unconsidered edge case.

In the last example above (I tested with/without the time element in the initial date string) my expectation from a user perspective is this is valid and should work. After all, I’ve given a valid date/time before passing modifications. Indeed, the fact the code works if $StartTime already holds a value, suggests the error if the attribute is set to"never" (i.e. default) is not the intended outcome.

I guess you need a fail-safe wrapper:

if($StartDate=="never"){
   $StartDate = date('now"); //pre-initialise the attribute
};
$StartDate=date("21/07/22 00:00"+"8 hours"+$Timestamp);

except that gives me the correct (day) date but with a time of “12:00”.

I give up! There are too many edge cases at play here … I think we need clarification as to how this is designed to work, allowed syntax variations, etc., before trying to address this problem. The inconsistency I’m seeing in test results indicates something broken.

Argh, it seems you can’t set a document’s default $DisplayedAttributesDateFormat as the Inspector is hard coded to use only the (one of three) choices on the Document Settings Text tab. which leads to another possible glitch.

Also, if an Interval value is entered as “00:15:30” (i.e. zero hours, 15 mins, 30 secs) when the note loses/regains focus, the interval is updated incorrectly to a value of “15:30”, (i.e. 15 hours, 30 mins, zero secs). I don’t think this glitch plays into the above but is definitely not functioning correctly. I suspect this latter issue tracks back to varying support over time for action code supporting seconds granularity. I think displayed Interval data should only show hh:mm if the seconds are zero, otherwise the Displayed Attributes table should show the seconds.

1 Like

In case it is of any help to anyone, my toolbox document (ref. forum post ) includes a technical Note with the name “Date/Time handling in Tinderbox” that provides a list of examples for how to assemble dates and times using various built-in methods. It is by no means complete, but I put this together as a crib sheet for my project work, and I often refer to it. Perhaps others might find this helpful. If anyone wants to suggest additions to this crib sheet, I will gladly add them to future updates.

Indeed, but a missing source reference is design intent what adding (or subtracting) Interval-type data from Date/Time-type data. My guess is both are the the same but black-box testing only gets one so far.

The other related issue, which seems to be a real edge-case glitch, is doing date/time arithmetic on an a new/undefined Date-type attribute. IOW, setting a base date and altering it in the same expression … or same action. Experiments above would suggest this is not possible (e.g. setting a date and the altering it ias discrete expressions in the action). I don’t think user testing can see far enough into the app to see where/why this goes wrong.

1 Like