Internal Time Representation

[Mike Schwartz]

Brendan,

While playing around with some formulas looking for a solution for Jean-Christophe’s problem with manipulating time data in a text calculation, I observed that a time value may be internally represented in two different ways depending on how it is entered into a Time field. Here’s the setup:

1) I have a Time field named Hours_Minutes, with Time Format HH:mm.
2) I have a Number Calculation field named Seconds. Its formula is simply [Hours_Minutes]. So it has the same value as Hours_Minutes, just displayed differently.
3) Now if I use the Accessory Control on my Hours_Minutes field, and set the time to 12:00:00 AM, then Hours_Minutes displays 00:00 and my Seconds field displays the value 18000. This shows me that you’re converting to seconds and using GMT. Since I’m in the Eastern USA time zone, Tap Forms (or MacOS) is adding 5 hours, or 18000 seconds, to convert to GMT. And if I use the accessory control and change the Hours_Minutes value to 12:01 AM, then the Seconds field displays 18060. So far, so good.
4) My starting point is the above, with Hours_Minutes displaying 00:01 and Seconds displaying 18060. Now if I directly edit the Hours_Minutes field back to 00:00 (I mean by highlighting and typing, rather than using the accessory control), then my Seconds calculation field suddenly displays this big number: 1494216000. That’s the number of seconds since January 1, 1970, the Unix Epoch big-bang. Roughly 47.38 years.

QUESTION: Why does the internally stored number for my Hour_Minutes field change depending on the method I use to enter it? If I use the accessory, then the Time field includes an “invisible” date of 1/1/1970. But if I direct-edit the field, then the “invisible” date is “TODAY”. This can cause some problems if I try to use a Time field in a calculation.

Is there a way for Tap Forms to store a consistent value regardless of which way it is entered?

Thanks,
Mike

[Brendan]

Hi Mike,

Well that seems to be a bug that you found!

… which I’ve just fixed now …

Would you be interested in beta testing? I can give you access to my beta versions of Tap Forms for Mac and iOS.

Thanks!

Brendan

[Mike Schwartz]

Wow, you probably spent less time fixing the bug than it took me to find, analyze, and write it up.

I’d be delighted to help out as a beta tester — I’m a pensioner with lots of time and I love Tap Forms! In my former working life I was a system engineer/CSPO at a large company and was involved with developing 9-1-1 Computer Aided Dispatch software. I’m not a programmer. My last assignment before retiring was to create requirements and user stories, define the user interface, and test the hell out of sprint releases.

Send me an email and let me know how I can help.

— Mike

[Brendan]

Hi Mike,

Just email support@tapforms.com and I’ll set you up with the betas.

[Brendan]

Ya, the bug was that for a custom layout, when you entered in a value, I was supposed to be calling a method that set the date part of the value to January 1, 1970, but the property I was checking was wrong. I had a property called “type” which I used to use to check the field type of a Field object and I’ve changed that property to “fieldType” to avoid a conflict that I was having with the “type” property. It turns out on a custom layout I was still referencing “type” instead of “fieldType”. I did have the code there to do the right thing, but the condition to execute it was incorrect. Thanks for finding that bug.

So it should actually work properly on the default layout currently though. The bug was just on a custom layout.

[Author]

Posts