Jed Frechette

As a user I would disagree with this. It may be OK on an ipad, but since there don't seem to any concessions to the smaller screen size it is pretty difficult to use on a phone.

+1 for this feature request. I see two potential use cases. A live read-only calendar(s) that ftrack users can subscribe to (authentication managed by the ftrack instance) so they can keep track of their ftrack schedule within their main calendar app. One-time export of a schedule snapshot as a static .ics file. This would be a good simple way to share schedule info with users outside the organization who don't need access to ftrack. The same could also be achieved with subscriptions, but a snapshot export would be a simpler way to manage non-sensitive data without worrying about managing credentials.

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: 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?

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.

Any updates on this work? Looking at the py3 branch on Bitbucket there haven't been any commits for 3 months and I was hoping we might hear more at SIGGRAPH, but I didn't see anything. Currently the ftrack-api is the major blocker preventing us from completing adoption of Python 3 so I'd love to get some hints about when we might expect a stable release that supports it. Thanks,