feat: remove monoclock & add tz as chain param

[MikaelVallenet]

based on #3016

---

fix #851

The purpose of this Pull Request is to simplify the Time pkg, which comes from Go, in order to remove unnecessary functions for Gno.

This Pull Request removes the concept of monotonic clock, which corresponds to the time since the start of the program, often used to calculate the time interval between two events more reliably.

I've also removed the notion of variadic timezone, and now an instance of Time is composed as follows:

type Time struct {
	sec  int64
	nsec int32
}

The timezone is now a const defined in timezoneinfo.gno see var chainLoc Location = Location{name: "UTC"}

When I parse a date with a different timezone, it's automatically transformed into the chain timezone.
However, the goal would be to allow a Time instance to be displayed in a specific timezone with a markdown pattern, especially for Gnoweb.

[2024-10-11 12:33:41](#local)
[2024-10-11 12:33:41](#Europe/Rome) => 2024-10-11 14:33:41 (Summer time)

Most of the PR is code deletion, not addition, especially the bitwise logic. see article

I also kept some unused param like Location in Date to validate the CI & keep same API as Go:

func Date(year int, month Month, day, hour, min, sec, nsec int, loc *Location) Time {...}

In the code snippet above, i kept the loc parameter even if i don't use it anymore. (i always use the chain tz)

I'd like to take this opportunity to say that I haven't answered the testing question, because the PR seems tedious enough to review as it is.

For what concerns testing, I think it's reasonable at the start of gno test to set a TimestampSeconds at the UNIX timestamp of starting the test. Or maybe we want it fixed in time... but, seeing as this is the testing environment, if we end up wanting to change it we can just change it later.
You may want to move internal/os.Sleep to the testing stdlib's time. Or maybe, let's have a SetNow which can take a time.Time to be set as the current value of Now().
Originally posted by @thehowl in #851 (comment)

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

📢 Thoughts on this report? Let us know!

[MikaelVallenet]

Hi @moul,

I see two ways to make a constant parameter as discussed in the last contributor call

• the first would be to add the chain timezone parameter in the genesis.json file in the same way as a chain-id
• the second would be to add a const prefix to the genesis_params.toml file, for example const:chain_tz, from which point on this parameter would be treated differently, notably in Setters, where it would not be modifiable.

I see an advantage in the second option, which is that you can easily change a parameter from const to non-const, whereas in the first option the timezone won't be modifiable regardless of the configuration. Now, do we want the tz to be modifiable on certain chains?

If you see a third or more options, don't hesitate.
What do you think?

[Gno2D2]

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

🟢 Maintainers must be able to edit this pull request (more info)

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Automated Checks

Maintainers must be able to edit this pull request (more info)

If

🟢 Condition met
└── 🟢 The pull request was created from a fork (head branch repo: MikaelVallenet/gno)

Then

🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission

[moul]

I was also considering adding a global variable to the standard library that is set to a custom value during its func init(). This would allow it to function like a "dynamic" constant within the package, eliminating the need to pass this fixed value everywhere. It would also make the standard library independent of parameters, std, and so on.

What do you think?

[MikaelVallenet]

I was also considering adding a global variable to the standard library that is set to a custom value during its func init(). This would allow it to function like a "dynamic" constant within the package, eliminating the need to pass this fixed value everywhere. It would also make the standard library independent of parameters, std, and so on.

What do you think?

Yeah i think it could be a good idea, at least for now and make it easier to implement.
I will update the code to do this in the following days 🚀