Current Time in GMT

[mattgoff]

The TM1 documentation doesn't specify what timezone NOW is in, but I've read a few places that it should be in GMT. However, it appears to be in local based on my tests. e.g. just now a server in Sydney returned 20166.278414352 and Singapore 20166.153113426. I do not have a tm1-log.properties file on either server, server logs are correctly recording in GMT, and both servers have the timezone correctly configured in Windows. Is this a bug, am I misinformed and NOW is in local, or is there some other setting I've missed? Alternatively, how can I get a timestamp in GMT?

Matt

[Alan Kirk]

The TM1 documentation doesn't specify what timezone NOW is in, but I've read a few places that it should be in GMT. However, it appears to be in local based on my tests. e.g. just now a server in Sydney returned 20166.278414352 and Singapore 20166.153113426. I do not have a tm1-log.properties file on either server, server logs are correctly recording in GMT, and both servers have the timezone correctly configured in Windows. Is this a bug, am I misinformed and NOW is in local,

The latter I think. I use Now() in conjunction with TimSt extensively and have for many years to get start and end times of processes in local, and in some cases to regulate chores which need to be run only in specific local time windows. In MOST cases local time is infinitely more useful than UTC but I know that there are cases when the latter would be more useful.

or is there some other setting I've missed? Alternatively, how can I get a timestamp in GMT?

Probably the easiest way would be to have a control cube in which you store the current offset, and have it calculated from a rule. As for how you update the offset when you switch on or off DST, that would have to be either manual or you could Heath Robinson a system which picks it up from the system; say, a TI which triggers a script which periodically writes the offset out to a text file, then loads it into the cube. Or alternatively a scheduled API kludge which does a similar sort of thing, logging into the server and writing the value. But manually is probably easier, as long as you remember to do it.

[Alan Kirk]

Further thought, and again this comes under the heading of Heath Robinson, TI error logs have the UTC datestamp, so you could theoretically get the necessary information from GetProcessErrorFileName. Theoretically, because there has to be at least one error in a preceding tab for that value to return anything other than an empty string. And intentionally generating log file clutter may b e a rather sub-optimal way of doing things.

[declanr]

Or if all of your servers are just for TM1 and you aren't using "local" times for anything (which it sounds like you probably aren't) you could just set the actual server time-zones to be GMT. Might confuse a few other admins mind you.

[Alan Kirk]

Or if all of your servers are just for TM1 and you aren't using "local" times for anything (which it sounds like you probably aren't) you could just set the actual server time-zones to be GMT. Might confuse a few other admins mind you.

And it's something you'd have to remember when you schedule a chore; since the input to that is "local" if you intend the chore to run at 09:00 (real) local you'd need to convert that to UTC before entering it, otherwise it will run at 09:00 UTC since the behind the scenes conversion from the server's "local" will be zero.

[rmackenzie]

how can I get a timestamp in GMT?

Code: Select all

sUTCTimeFile = '\"' |  GetProcessErrorFileDirectory | 'utc_time.txt\"';
sCmd = 'powershell -command "& {Get-Date -date (Get-Date).ToUniversalTime()-uformat %Y%m%d%H%M%S | Out-File ' | sUTCTimeFile | '}"';
ExecuteCommand ( sCmd, 0 );

[mattgoff]

Thanks all. Robin's method is the one I implemented-- rather not deal with manual corrections for DST, easier to just suck up writing a file and importing it. My process was using datasource none so luckily I was able to build it in to the existing process instead of creating an extra/child one. For once.

Ironically this process is an alerting system I'm having to implement to ensure that all of my repsyncs are successful. I'm writing a checkval and UTC on each of my planets to a control cube. I can then easily inspect them on the star to ensure that a) the time is recent (replication occurred on schedule) and b) the checkval matches the local cube value (all cells replicated correctly). *sigh*

Matt