A client who was using SeedCode’s DayBack calendar wanted to implement Dayback’s Zoom integration to be able to schedule Zoom meetings directly from the calendar. Fancy schmancy stuff. So I set it up. It didn’t work.

Well, not at first, anyway.

This was unusual for a product that has had maybe a gazillion users before me, so I immediately began looking for what I did wrong. But, unlike most times, I couldn’t readily find my mistake. I put on my diving suit and prepped for a deep dive.

We eventually got it working. And by “we” I mean myself and KC at SeedCode, who is a rockstar-and-a-half when it comes to customer service. The solution was something I didn’t know about. I hope by showing you this tip that you can avoid having to troubleshoot all the way under FileMaker’s hood like we did.

Here’s What Happened

The Zoom API was rejecting my request for scheduling a meeting, so we took a look at the data being sent to zoom:

Uh-oh. There were question marks in the timestamps. No wonder Zoom responded like an irritated amusement park security guard. I wasn’t giving it good data to work with. Ok – that was good to know, but what was causing the disconnect?

We looked deeper and found this:

I checked the date being sent, the time being sent, and the result being returned in the variable “ts”:

The GetAsTimestamp function was returning something weird. So I ran two tests.

Test One

Test Two

The Discovery

After investigating, KC let me know that the use of GetAsTimestamp in this case was causing the issue. He said that the Timestamp function is designed to receive an actual date and time, while the GetAsTimestamp function is meant to turn a text string into a timestamp. This means that GetAsTimestamp requires precisely formatted values for it to work, while Timestamp is expecting date and time values, so it tolerates shorthand similar to fields that are defined as either dates or times.

During our tests, we found that 10 AM was being passed as a time and not text, so this is not a type mismatch error. It appears that GetAsTimestamp is not formulated to interpret time data. It relies solely on the format of the string(s) being used.

The Fixes

As a result, there are two possible fixes to our specific problem. I’ll mention both because it’s always nice to have more than one solution in one’s toolkit. The first method is using the Timestamp function as stated, which looks like this:

The second is creating an extra step that checks the time, and amends the “:00” as necessary:

The Timestamp function is elegant insomuch as it changes the smallest amount of code, so that seemed to be the best answer here.

Knowing which function to use reminded me of the discussions about when to use IsEmpty versus IsValid when looking for the existence of related records. Back when this was a topic in the community, I learned from places like SixFriedRice who posted this explanation. Yes, the date on that post is 2007. Man, I’m old.

Either I’ve never run into this timestamp issue before, or I’ve fixed it in other ways without really investigating. I don’t know which one it is. The point is that knowing the use cases behind the tools in our collective toolbox will help us all be better developers.

We Love Figuring Out Edge Cases

Every large system has edge cases like this that need to be addressed. If you would like us to help you review your system with an eye towards making it faster, less brittle, and more flexible for the future, let us know! Comment below and let us know what you’re needing. We’d love to help you! You can also schedule a complimentary 15-minute consultation.

We’re hiring a FileMaker Developer! This fully remote position is a great opportunity to join a successful, growing team of FileMaker developers based in the Seattle area, but doing work for clients around the country. We’re working on some of the most cutting edge FileMaker technologies – the FileMaker data API, 3rd party REST API integration, and always the latest versions of FileMaker. Apply now!