Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

-SIPC-/time: some bug fixes and new blocks #928

Merged
merged 31 commits into from
Jan 28, 2024

Conversation

SharkPool-SP
Copy link
Contributor

@SharkPool-SP SharkPool-SP commented Aug 23, 2023

Moved From: #752 (comment)
(OG .js base file was outdated)

Adds several new calculation blocks for time!
Note: Fixed Several Bugs from Before AND added new blocks!!...
Screenshot 2023-09-16 212935

@SharkPool-SP
Copy link
Contributor Author

Screenshot 2023-09-06 222521
Added 2 new Blocks!!!

@GarboMuffin
Copy link
Member

GarboMuffin commented Jan 28, 2024

you're probably gonna be pretty unhappy:

  • removed countdown blocks: they are redundant, one can just invert the difference block that already exists
  • removed blocks that have unintuitive dependence on the unix epoch: the statement that "January 1, 1970 + January 27, 2024 = January 27, 2024" just doesn't really make sense. If someone wants to unix them as unix timestamps, the tools are already there for them to do that themselves.
  • Similarly the statement "convert January 27, 2024 to years = 54.11020848940893" just doesn't seem very useful, and again its already easy for someone to compute with the existing blocks

@GarboMuffin GarboMuffin changed the title Time V2 (Fixed) -SIPC-/time: some bug fixes and new blocks Jan 28, 2024
@GarboMuffin GarboMuffin merged commit 195d3e4 into TurboWarp:master Jan 28, 2024
3 checks passed
@SharkPool-SP
Copy link
Contributor Author

you're probably gonna be pretty unhappy:

  • removed countdown blocks: they are redundant, one can just invert the difference block that already exists

  • removed blocks that have unintuitive dependence on the unix epoch: the statement that "January 1, 1970 + January 27, 2024 = January 27, 2024" just doesn't really make sense. If someone wants to unix them as unix timestamps, the tools are already there for them to do that themselves.

  • Similarly the statement "convert January 27, 2024 to years = 54.11020848940893" just doesn't seem very useful, and again its already easy for someone to compute with the existing blocks

Fine by me

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

Successfully merging this pull request may close these issues.

2 participants