Jump to content

Auto-Enter Get( CurrentHostTimestamp)


This topic is 3654 days old. Please don't post here. Open a new topic instead.

Recommended Posts

It would sure make more sense (to me) if the critical creation and modification timestamps of a record used Get(CurrentHostTimestamp) instead of the client value.  I have just ran across such a confusion where the unsorted state of a table shows last record with creation date BEFORE its prior record.  One was created in US and the other in Australia.

 

Get ( CurrentHostTimestamp) would use the client's timestamp if server were unavailable (which it does now) so it really covers all bases, right?  Of course we can add an auto-enter calculation but wouldn't it make more sense to let us handle it when we define the field?  It could be as simple as adding radio button (please see example).

 

With the world of mobile, accessing from around the globe, and considering our servers might be on opposite days, having this control might be helpful in ways I haven't yet considered so I would love all your input before I decide whether to send the suggestion to FMI.

 

 

post-59345-0-83358600-1392844801_thumb.p

  • Like 2
Link to comment
Share on other sites

"The standard ISO-8601 timestamp includes a time zone or offset from UTC."  Would you say this a bit easier for me, Comment?

 

ISO-8601 is what the local computer uses?  What is offset from UTC?  It seems like a complex subject.

Link to comment
Share on other sites

Thank you, Michael.  The more I consider this the more concerned I become by my lack of experience accepting input into single table from multiple venues with different regional settings.

 

For others reading, I always create files in the format of the country which will be using it and set 'use current settings' as protection.  But with 13, if Locations are in New York, Australia and Great Britain and they share the same table, how do we handle currency and timestamp differences?

 

Each Location will be constrained to their own records using Security but UI and server-side scripts might be effected if I am not very careful.  For instance, when does month-end (server-side) process run?  If it runs on Server's month-end then that might not be a Location's month-end.  Or how will my Calendar in UI behave when it displays records for Thursday?  Whose Thursday?

 

I will include the Host's timestamp (or maybe Greenwich World Time?) so I can at least normalise the timestamps but I am still unsure how different regional settings can share same table and where else this might bite me.  It makes me feel like a major local bumpkin which I am.  :jester:

Link to comment
Share on other sites

I'm not sure it's as bad as you make it sound. However, you do need to decide what you need first. If each group of users is constrained to one location, what do they care about the host timestamp?

 

In a more "mixed" environment, it might be necessary to identify each user with a location, and the location with a time-zone or UTC offset.

Link to comment
Share on other sites

I'm not sure it's as bad as you make it sound. If each group of users is constrained to one location, what do they care about the host timestamp?

 

If I schedule a cloud server in Australia to post all records at month-end, it will use ITS date to fire.  That would post (freeze) receipts for US Locations roughly 17 hours too soon (so actually a day) so yes I consider it a bad thing but only bad if one doesn't recognise it.  I have the feeling that others may not realise this potential issue either with the huge movement to cloud servers from around the world.

 

The requirements are mixed with Users (potentially) working at multiple Locations (independent contractors working with different businesses) and, although I do not believe they would cross Regional boundaries, I could not guarantee they wouldn't.  We'll include an offset in the Locations table to synchronise the two and I planned to use a checkbox of LocationIDs in the Users table.

 

Hey, thanks for speaking up.  :wink3:

Link to comment
Share on other sites

If I schedule a cloud server in Australia to post all records at month-end, it will use ITS date to fire.  That would post (freeze) receipts for US Locations roughly 17 hours too soon

 

But does it really matter when exactly the server script fires - as long as it does not fire before the month ended in all locations? That would shift the problem to the data side - and if the data were tagged with the local time, then the script would know which data belongs to the previous month for each location.

Link to comment
Share on other sites

True; as long as it does not fire before ALL Locations are through.   And in which case, the client timestamps WILL be important to use for gathering the appropriate data and not host timestamp.  Still, it will be important to consider ... take for example, Perform Script On Server[] where part of the script uses the current date for a find.  Will that be the date the client wants?

 

I appreciate your clarity.  It is helping me feel more comfortable.  A bit of uneasiness still lingers but with me, it probably always will, LOL. 

Link to comment
Share on other sites

take for example, Perform Script On Server[] where part of the script uses the current date for a find.  Will that be the date the client wants?

 

Probably not. That's what I meant earlier when I said that you must decide what you need first. You can't have a "one size fits all" solution here, IMHO - you need to examine each case individually. For example, the script should probably use a script parameter instead of getting its own current date.

  • Like 1
Link to comment
Share on other sites

Yes, each interaction will need to be thought through.  And I just realised in the case of month-end, our business rule dictate closing on the 5th of the following month which allows Users time to complete data-entry and make manual accounting adjustments first.  So although we are searching for records dated the prior month, we do not want to cut them off before the 5th so we will still need to handle month-end by Location so their records are frozen on their 5th.

 

Considering every need individually and passing script parameter will be important here.

Link to comment
Share on other sites

One more thought has occurred to me: what would happen if you changed your host's location?

 

Why am I bringing this up? To illustrate that Get (CurrentHostTimestamp) is NOT an attribute of a transaction. A transaction recorded in New York with the timestamp of the server in Sydney becomes "out of sync" with a later transaction recorded in New York with the timestamp of the server in  Los Angeles. In order to get everything back on the same timeline, you would need to adjust the old transactions' recorded timestamps - and that's a clear sign of poor structure.

 

Recording both the local timestamp and the location should provide all there is to know about when a transaction took place. And if you also record the UTC, you won't have to figure out when a particular location switched to or from daylight saving time.

  • Like 3
Link to comment
Share on other sites

WOW.  I am so glad we are talking this through.  I did not consider that at all. 

 

So a transaction must be dated according to its perspective (the Location) no matter its time zone or region.  This is easy for me to assimilate -  in FileMaker, everything is perspective (and proportion). ;-)

Link to comment
Share on other sites

no matter its time zone

 

Time zone would matter if you wanted to compare the times of two transactions from different locations. Even then, the time zone would be an attribute of a Location, so this would be quite simple - except for DST, which is the proverbial fly in the ointment here.

Link to comment
Share on other sites

So if I as a client am in Bakersfield and I have our server file clouded in Australia and I have a calculation which includes unstored get current date, which date will the calculation evaluate from?  The server where the unstored calculation lives or the client who asks?  Sorry, I cannot test myself.  

 

This is a great conversation guys, thank you.

Link to comment
Share on other sites

Time zone would matter if you wanted to compare the times of two transactions from different locations. Even then, the time zone would be an attribute of a Location, so this would be quite simple - except for DST, which is the proverbial fly in the ointment here.

 

Your points are critical ... no matter the solution being discussed.  AFAIK, the only way to truly track time zone is with web viewer which looks it up regularly (with each sign-in?).  That is (sort of) why I mentioned World Clock.  But I am out of my element on this discussion of world-wide solutions and I bow to your extended knowledge on the subject.

 

I had not seen the Knowledge Base article referenced ... it is an important piece in the constantly-shifting plate tectonics of FileMaker evaluations.  When shift from client to server takes place in a version such as 12, we need to know about it.  It seems that every single Updater from FMI changes behaviour in at least one way and must be tracked by those of us with multiple solutions build (or being built) in multiple version/updaters.

 

One thing for sure ... we are never bored keeping track of it.

 

Did I say thank you, Michael?  You know I always mean it.  Sometimes we get busy but I always mean it.

 

Hey Rick ... when comparing the meaning, it seems the two are similar (bumpkin and bupkis) but maybe not.  It reminds me of word origins which is almost as fascinating as tracking the origins of man across Africa/Eurasia.  Cool stuff, all of it. :-)

Edited by LaRetta
Link to comment
Share on other sites

AFAIK, the only way to truly track time zone is with web viewer

 

It depends. I need to make a small, but important correction to my earlier post:

 

"The standard ISO-8601 timestamp includes a time zone or as an offset from UTC."

 

This means that a timestamp like "2014-02-25 23:46:11 (PST)" is not part of the standard and you must use "2014-02-25T23:46:11-08:00" instead.

 

The difference (for our purposes) is that while Filemaker cannot generate or consume a timestamp where the time zone is indicated by an abbrevation without getting some help from the outside (such as a web viewer), it definitely can generate and understand timestamps of the latter format. It's only a matter of calculating the difference between Get ( CurrentTimeStamp ) and Get ( CurrentTimeUTCMilliseconds ) (after adjusting the units to a common base).

 

Another difference is that this type of timestamp must be an attribute of a transaction. A location's offset from UTC can change twice a year, so saying that a transaction took place in location X on date Y at local time Z doesn't tell the whole story, unless you also know the daylight saving time rules for that location (which may change from time to time, and often do).

 

 

I had not seen the Knowledge Base article referenced

 

It used to be part of the help system, IIRC.

 

 

it seems the two are similar (bumpkin and bupkis) but maybe not.  It reminds me of word origins which is almost as fascinating as tracking the origins of man across Africa/Eurasia.

 

bumpkin ≠ bupkis

 

Speaking of word origins, this one's are fascinating - it went through at least four languages to get to the current form.

Link to comment
Share on other sites

  • 1 month later...

As I have a system with users in two different timezones, I've been playing around with different time systems, and I think it's important to mention that Get ( CurrentTimeUTCMilliseconds ) uses the system clock, but (at least on OS X 10.7.5) uses the actual timezone it's in. In other words, if the clock is off the time is off, but changing the timezone of your clock still returns the actual timezone's UTC offset. Weird.

 

So if you're looking for system accuracy, you probably shouldn't rely on Get ( CurrentTimeUTCMilliseconds ) because who knows what the client's clock is set to?

 

If moving servers is an issue, then I don't know the answer.

 

But you can get your current client offset with ( get ( CurrentTimestamp ) - Int ( Get ( CurrentTimeUTCMilliseconds ) / 1000 ) ) / 60 / 60

And that's accurate whether your clock is wrong or not.

 

**Edit

It seems like if you're not connected to the Internet, FMP uses your system clock's timezone, but if you are it calls out to find it.

  • Like 2
Link to comment
Share on other sites

This topic is 3654 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.