Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Add TIME for when the runtime started #365

Draft
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

RobLoach
Copy link
Contributor

@RobLoach RobLoach commented Jan 28, 2022

Introduces a TIME constant which is an unsigned 64 bit integer representing the unix timestamp of when the runtime started in seconds. It also includes a sample clock application. This would be helpful for creating time-sensitive applications, like...

  • Clocks
  • Calendar applications
  • Persistent games, like Tamagotchi

Screenshot at 2022-01-30 19-42-25

TODO

This isn't ready to be merged as it...

  • Needs more testing
  • Is the Hour calculation correct?
  • Fix the web build
  • Needs some tweaks in some of the languages (DataView doesn't support uint64 right now for instance?)
  • Is TIME the most descriptive constant name?

runtimes/web/src/runtime.js Outdated Show resolved Hide resolved
@RobLoach RobLoach changed the title Add START_TIME to retrieve when the runtime started Add TIME for when the runtime started Jan 31, 2022
runtimes/web/src/runtime.js Outdated Show resolved Hide resolved
@JerwuQu
Copy link
Contributor

JerwuQu commented Feb 2, 2022

Might be worth documenting a special case where TIME can be set to 0 for MCU-based devices (i.e. arduino) which won't have a system clock, so that games can handle that.

I think something like INIT_TIMESTAMP or START_TIME might be more clear than just TIME, since it both signifies that it will be set once on startup, and (for the former suggestion) that its a unix timestamp rather than something else, but this point is a bit subjective.

For languages that don't support reading u64 yet (DataView should be the only case, right?) it might be OK to just read the lower 32 bits for now. That leaves them safe up until the year 2106, and hopefully they decide to support it before then :)
I'd recommend opening an issue upstream for this.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants