@jbante tweeted he discovered a previously undocumented feature in FMP12 - Get (UTCmSecs)

Example:

GetAsTimestamp ( Get ( UTCmSecs ) / 1000 )

Very interesting...

Actually, @koenvanhulle mentioned it in a thread on TechNet, which is where I read about it.

Playing devils advocate.

If the code was stumbled upon, is undocumented, and doesn't even appear as a function or feature in the help or listed as a functions, why would you risk using it in one year permanent solution, betting that it might be implemented in an update to version 12?

Lee

To answer the devils advocate, I think the key word there is "permanent." Sometimes we're willing to trade stability of a feature for some other value, such as convenience. In the case of Get ( UTCmSecs ), I can use Java's System.nanoTime() for sub-second timestamps, but then I need to have and use ScriptMaster, which creates a dependency and doesn't work for FileMaker Go. I can open a page with the current UTC in a webviewer and scrape the contents, but a Get function is so much simpler.

Also, change is life. Folks wanting a "permanent" solution should be navigating by astrolabe rather than GPS — you never know when those satellites will fall out of the sky. This analogy is extreme. There is a continuum of how long we expect features' behavior to remain consistent (and available, for that matter), and a continuum of how long we need to expect a behavior to last before we're willing to depend on it for a particular application. Prototypes depend on early adopters to popularize them enough for popular demand to demand equivalent longer-term solutions.

Also, change is life. Folks wanting a "permanent" solution should be navigating by astrolabe rather than GPS — you never know when those satellites will fall out of the sky. This analogy is extreme.

You think! It is also insulting. Whatever made you think I was against change?

I apologize. I don't mean to be insulting. Only hyperbolic. I did not think or mean to suggest that you are against change, only that your stimulus for further discussion was premised on the resistance to change implied by a "permanent" solution. My point was only that permanence is asymptotically impractical, and so some level of impermanence must be accepted, at which point it becomes reasonable to accept varying levels for varying purposes.