Occasionally game completed time is far in the past

[mvines]

eg,

No good STR right now beyond waiting for user reports, this could use some investigation.

I suspect that we're getting a timestamp of 0 somehow since we use UNIX epoch in the tictactoe webapp.

[mvines]

I'm now seeing this issue consistently after any game

[sunnygleason]

@mvines looks like both programs use tick_height now instead of a client-provided timestamp.

https://github.com/solana-labs/example-tictactoe/blob/master/program-native/src/lib.rs#L179
https://github.com/solana-labs/example-tictactoe/blob/master/program-bpf/src/tictactoe/tictactoe.c#L385

This appears to have changed in this commit:

ae874e9

The Solana Rust SDK looks like it has a timestamp() function, but I couldn't find one in the BPF sdk:

https://github.com/solana-labs/solana/blob/master/sdk/src/timing.rs

Do you have a preference for how this gets fixed?

1. very lightweight, no program change: web client keeps track of tick_height to epoch millis
2. similarly lightweight, no program change: node "server" keeps track of tick_height to epoch millis
3. least lightweight, program change(s): program state include epoch millis as data structure

Thank you in advance for any advice you may have!

[mvines]

(3) would be nice as a longer term fix. In the immediate term I'd be fine with option (0), just hide the recent game time from the UI though :)

[sunnygleason]

@mvines awesome, (0) is already implemented on the custom-testnet branch:

1605217#diff-1e5251f0c8caa1a663183aa6b0bd36e3R221

I'll start a dev task to make the changes in (3) over the next few days (there
are probably a couple visualization tasks which are higher priority)

[mvines]

Please revert 458adce as a part of fixing this issue