https://discord.cloudflare.com logo
Join Discord
Powered by
# workers-discussions
  • w

    Walshy | Pages

    03/28/2023, 11:22 PM
  • a

    avi

    03/28/2023, 11:23 PM
    oh wow
  • k

    kian

    03/28/2023, 11:23 PM
    Work around? None, really - but it depends what accuracy you want
  • k

    kian

    03/28/2023, 11:23 PM
    It's intentionally inaccurate, and any workarounds to update the time are varyingly inaccurate.
  • a

    avi

    03/28/2023, 11:23 PM
    i need accuracy += 100ms
  • a

    avi

    03/28/2023, 11:23 PM
    it's a timer for a game server
  • k

    kian

    03/28/2023, 11:23 PM
    When you're doing I/O (fetch, KV, cache, etc) then it'll update somewhat
  • k

    kian

    03/28/2023, 11:23 PM
    If you're just doing compute in the Worker, don't expect any updates
  • a

    avi

    03/28/2023, 11:24 PM
    i need updates though lol
  • k

    kian

    03/28/2023, 11:24 PM
    You can use a remote timing source that's probably sub-50ms of latency, but that's about it
  • k

    kian

    03/28/2023, 11:25 PM
    You can use
    await scheduler.wait(ms)
    or what Walshy posted, just keep in mind that the timer that backs those timeouts is Spectre-safe so it won't really wait that many milliseconds, but it should be close.
  • w

    Walshy | Pages

    03/28/2023, 11:25 PM
    I always forget scheduler.wait, much better
  • k

    kian

    03/28/2023, 11:25 PM
    i.e
    Date.now()
    ,
    fetch(..., { signal: AbortSignal.timeout(1000) })
    ,
    Date.now()
    will give you a delta of 1000 - but it isn't really 1000ms of wall-clock time, but it should be close enough for your use-cases imo
  • k

    kian

    03/28/2023, 11:25 PM
    my favourite API
  • a

    avi

    03/28/2023, 11:26 PM
    yeah this is a turn-based game, so i really do not care about accuracy very much at all
  • a

    avi

    03/28/2023, 11:26 PM
    if a human wouldn't notice it's off, it doesn't matter
  • a

    avi

    03/28/2023, 11:27 PM
    probably 100ms is plenty
  • k

    kian

    03/28/2023, 11:27 PM
    Sleeps will advance the clock, with varying inaccuracy (lots of CPU = lots of inaccuracy) - see if
    await scheduler.wait(1); Date.now()
    is good enough for you
  • a

    avi

    03/28/2023, 11:27 PM
    i still don't understand why Date.now() is frozen in
    --local
    but not in
    --experimental-local
    ?
  • k

    kian

    03/28/2023, 11:28 PM
    Not being done in
    --local
    is likely just a discrepancy between development and production since
    --local
    is a Node emulation whereas
    --experimental-local
    uses the open-source runtime
  • a

    avi

    03/28/2023, 11:28 PM
    i'll need
    node_compat = true
    right?
  • w

    Walshy | Pages

    03/28/2023, 11:28 PM
    Miniflare freezes unless you do --real-time (though the way it freezes the time isn't 1:1 with Workers)
  • k

    kian

    03/28/2023, 11:29 PM
    That's just for some Node polyfills - it depends on your code (and dependencies)
  • k

    kian

    03/28/2023, 11:29 PM
    They're not the best, and
    compatibility_flags = ["nodejs_compat"]
    is better ones built into the runtime - but there aren't very many modules covered by it just yet
  • a

    avi

    03/28/2023, 11:29 PM
  • k

    kian

    03/28/2023, 11:29 PM
    It shouldn't need to be imported
  • a

    avi

    03/28/2023, 11:29 PM
    i'm just trying to call
    scheduler.wait()
  • w

    Walshy | Pages

    03/28/2023, 11:29 PM
    No need for an import
  • k

    kian

    03/28/2023, 11:29 PM
    It exists on the global scope as-is
  • k

    kian

    03/28/2023, 11:30 PM
    Pretty much all of the Workers APIs sit on
    globalThis
    - the only things that need importing is the Node polyfills if you use those
1...236423652366...2509Latest