Get(CurrentHostTimestamp)

[LaRetta]

Help from the Forum, please.

With all options FM7 has for getting the current date & time, you wouldn't think I would be concerned ... but I am.

None of the clocks through our small network stay consistent. Do all of yours? I use Auto-Enter Creation TimeStamp, Creation Time, etc. and I use Get(CurrentTime) or Get(CurrentTimeStamp) when scripting. But Get(CurrentHostTime)? That has opened up questions and uneasiness.

We are networked so each User accesses the host file. So if records are created, does it use the host file creation & modification time or the User's? It must be the User's time because otherwise why is there a Host time? But since records are created in the host, it makes no sense that it doesn't use the host time!

FM has that Get() function for a reason so it must be important. FM Help just tells me what it does but not the logic of when to use it. And my mind circles the issues of a time conflict if this isn't handled properly. I feel I should standardize by using the host time. But Auto-Enter doesn't. And I imagine issues, such as SecureFM not firing because the Mod Time in a field shows one thing and if I use Host Time within a script, SecureFM may mis-fire - only one example ... there probably are more!!

I feel the need to question these issues and not simply blow off their possible importance. I need to get a grip on time. Are there reasons time-handling can be important?

LaRetta

[LaRetta]

Hello everyone,

Hmmm, no replies means this post got lost in the shuffle or no one has any opinion about using time fields? Am I nit-picking here? I would think it might be important but I guess not.

Then I'll drop the concern unless I get additional feedback.

LaRetta

[Ender]

I'm planning on using the Get(CurrentHostTime) function to at least test if the local computer's clock is way off, if so I can notify the user at login.

I'd like to somehow guarantee that the dates and times that are auto-entered are correct. I hate going into a file and seeing 1/1/1904 as the creation date (which happens when a clock battery dies.) As you guessed, using Get(CurrentDate) and Get(CurrentTime) get the date and time from the local computer.

In an ideal setup, you would have your computer check a time server at startup to get the correct time. This avoids some of these issues (though I did have a case where the time server was giving out bad dates!) In this case, getting the Host Date/Time is not so important. But here's a case where it still is useful: I have an Equipment Auction database that's kind of like ebay for our staff to purchase used company equipment. In this case it's important that the time stamp of their bid be syncronized with the server.

[LaRetta]

Thank you Mike.

In this case it's important that the time stamp of their bid be syncronized with the server.

And I am also implementing a Time Card solution, utilizing login/logout (with additional options for breaks and lunch, so they can stay logged in). Everyone disagrees on the time. I see this as a big issue for us if it isn't standardized by the time this goes into effect.

I have no idea what a time server is ... guess I'd better get busy finding out. I will be implementing Server 7 Advanced (within the next few days hopefully); although I may hold off til the weekend. I wonder how this will effect time (or will it?) - never used FM Server before. I will be tickled to dump peer-to-peer, that's for sure.

LaRetta

[Fitch]

Try going to www.versiontracker.com and search for "time" or "clock" or "synchronize." You'll find at least a dozen programs that synch your computer's time with an atomic clock in some lab or naval base.

Time in/out shouldn't be a big deal even if the user's clock is wrong, as long as they log in and out from the same machine -- i.e., the interval will be correct, which is the important thing. Unless they're savvy enough to monkey with their clock... but there are ways to limit that too, depending on the OS.

[Ender]

If you have a lot of workstations, then it might be easier to use that new host timestamp function. Although your users might wonder why the database inserts a different time than what they see on their computer's clock.

I was thinking of doing a check like this at login:

If [ Abs ( Get ( CurrentHostTimeStamp ) - Get ( CurrentTimeStamp ) ) > Time( 0; 5; 0 )

#Clock is more than 5 minutes off

Show Custom Dialog [ "Your computer's clock is incorrect. Please call tech support..." ]

Halt Script

End If

That way it allows for minor differences in the clock syncronization, but will stop users from proceeding if the clock is too far off.

But then again, if you're building an FM7 solution from scratch, then you might just use the host timestamp function for ALL date/time auto entries, ignoring completely the client workstations' clocks. (And if the solution is not hosted, it will simply return the date/time of the computer it's running on.) Maybe build simple customs functions Get(HostTime) and Get(HostDate).