get Ftrack server current time

[Jakub Trllo]

Hi, we've got issues with starting timer of users. In most of cases start of timer is offset by 1 minute apart, but we have reported issues that timers are offset more than tens of minutes. With ability of getting server time this would not be issue at all. With server time delta it is easy to start timers or add/edit timelogs withit API. Is that possible now?

Thank,

Jakub Trllo

[Guest]

Hi Jakub,

 

Could you give some more examples, please? You're starting a timer through the web UI, not the API, right? And the server is one of our cloud instances or something you have installed locally? Assuming you're using the web UI, is the duration correct but just the start and end times offset?

There is/was a bug where reloading the tab which started the timer, or stopping the timer in a new tab or browser would cause an offset. (The duration would be correct, but the stop time would be recorded as the start time and the recorded stop time would be in the future.)

[Jakub Trllo]

Hi Steve Petterborg,

 

sorry for not enough info. No, server is not installed locally and don't know how to find out if it is cloud instance? (`pype.ftrackapp.com`) No, timer is not started with web UI, but with python API, through user entity's method `start_timer()`, with that approach web UI shows timer started, on our server it is 1 minute ago, so web ui timer shows -60 seconds(and counting to 0 second and beyond). But in my case of our server start/stop of timer through the web UI works perfect, don't know if other clients found these issues.

 

BTW: When I checked Timer creation event, it really shows that `start_time` value is offset (at least to my `arrow.now()` value), but I would expect it doesn't matter if my current time is offset, because python API does not set that `start_time` value.

 

REASON: I expect that `start_time` value is set by the server, which means that the server has offset system time. If there is ability to query server's current time it is easy to find out delta and override `start_time` value with right value.

Jakub

[Guest]

Hi Jakub,
 

Sorry I missed your reply. (Now following the thread.)

 

Thanks for the info, it gives me something to try out, and I'll verify with dev ops that the server time is/how to query it. My guess is your best bet would be to start and stop a timer through the web UI, then query that through the API, and compare the reported time with a time service to determine whether the recorded server start time matched what you would expect.

[Jakub Trllo]

Hi @Steve Petterborg,

any progress? We found another reason why we need server's current time (in UTC format), we want to be able create timelogs for specific hour and minute. That is totally impossible without knowing server's (or database's) time right?

Jakub

[Guest]

Hi Jakub,

I believe you can query the server time with simple HTTP methods and examining the "Date" header.

Alternately I can calculate and adjust for the offset this way:

    timer = current_user.start_timer(task)
    print timer['start'] - arrow.now()
    timer['start'] = arrow.utcnow()
    session.commit()

Due to old issues with automatic time and date on macOS, my laptop is a consistent 1.7 seconds behind official time, as reported by my server or time.gov. Since the local API session controls the end time, and therefore duration, of the Timelog, offsetting the start time when I create the Timer seems the easiest way to ensure the correct duration later. However, if you have different processes with different offsets running, then maybe you should leave the Timer object in server-time, and adjust the Timelog duration after you stop the timer.

[Jed Frechette]

On 1/10/2020 at 2:05 AM, Jakub Trllo said:

No, timer is not started with web UI, but with python API, through user entity's method `start_timer()`, with that approach web UI shows timer started, on our server it is 1 minute ago, so web ui timer shows -60 seconds(and counting to 0 second and beyond). But in my case of our server start/stop of timer through the web UI works perfect, don't know if other clients found these issues.

We see similar behavior on an ftrackapp.com hosted instance. In our case though the timer starts at -30, counts down to 0, resets to -60, counts down to 0, resets to -60, ... When stopped via the Web UI reports a negative value for the timelog.

Using utcnow to set the start time after starting the timer works, but that seems like an awfully janky workaround, for a function that should just work.

[Guest]

Hi Jed,

Thanks for the report. Does it always happen that way? Server time seemed fine when I pinged your instance with curl just now. The behavior with the timer looping through negative numbers sounds very odd. What's your code look like for starting timers? I continue to test with something pretty minimal:

session = ftrack_api.Session(auto_connect_event_hub=False)
current_user = session.query(u'User where username is "{0}"'.format(session.api_user)).one()
task = session.query('Task').first()
current_user.start_timer(task)

[Jed Frechette]

1 hour ago, Steve Petterborg said:

Does it always happen that way? 

I think so. I haven't tested in a bunch of different environments, but everywhere I have the observed behavior seems to be consistent. The actual code is inside a Connect hook so there is quite a bit more boilerplate, but the essential bit is very similar to yours:

Quote

    def start_task(self, event):
        """Callback method for Start Task action."""
        task = self.session.get("Task",
                                event['data']['selection'][0]['entityId'])
        user = self.session.query("User where id is {}".format(event['source']
                                                               ['user']
                                                               ['id'])).one()

        timer = user.start_timer(task, force=True)

I just tried with a even simpler standalone script based on your example and the behavior is the same. It also looks like if I let the timer run long enough it eventually does become positive and starts counting forward.

If I understand this issue correctly it is due to a time offset between the user's machine and the server. If that is the case wouldn't it be best to always use the server time as reference as that is the only one that's guaranteed to be consistent regardless of whatever time deltas might exist on the particular machine a user happens to be accessing it from?

[Jakub Trllo]

I've tried to get Ftrack server's time via GET request and it seems that time from Ftrack server matches mine (tried only once a while ago). Maybe problem is with database time?

[Guest]

Jed, I agree being more consistent in which time we use sounds reasonable.

 

I rolled the system clock back on a local install, and here's what I observed:

GET reflected the "slow" clock. A timer started via the API began with the expected amount of time on the clock, as displayed in the browser. Starting and stopping a timer with the API convenience methods created a timelog which showed the delta between the server and local time.

 

I'll be really surprised if the various services that make up the cloud implementation could have different times, but I'll need to run that by some folks in the office.