You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TL;DR make all TTL references in codersdk be milliseconds instead of nanoseconds.
Initially when defining the external API for workspace time-to-live (TTL), I simply passed through the Golang time.Duration object as an int64. This is a nanosecond timestamp, which means that the typescript UI needs to multiply/divide any timestamps by 1 million.
This is a potential source of future time-bugs (the worst kind of bugs), so it would make sense to align the typescript API with what JS/TS generally uses for timestamps (milliseconds).
remark (non-blocking): in a follow-up PR, I think it could make sense to migrate `ttl` to `ttl_ms` in externally-facing API types so that we don't accidentally multiply by a million one way or another. Milliseconds seems to be the accepted unit of time in the TS/JS world.
This issue is becoming stale. In order to keep the tracker readable and actionable, I'm going close to this issue in 7 days if there isn't more activity.
This issue is becoming stale. In order to keep the tracker readable and actionable, I'm going close to this issue in 7 days if there isn't more activity.
TL;DR make all
TTL
references incodersdk
be milliseconds instead of nanoseconds.Initially when defining the external API for workspace time-to-live (TTL), I simply passed through the Golang
time.Duration
object as anint64
. This is a nanosecond timestamp, which means that the typescript UI needs to multiply/divide any timestamps by 1 million.This is a potential source of future time-bugs (the worst kind of bugs), so it would make sense to align the typescript API with what JS/TS generally uses for timestamps (milliseconds).
Originally posted by @johnstcn in #1701 (comment)
The text was updated successfully, but these errors were encountered: