[ttytm]

The PR fixes issues like #17162 and #17311

The fix does NOT add the @[noinit] attribute to the Time struct, as doing so would break its use in other structs, such as:

struct Foo {
	t time.Time
}

foo := Foo{} // would not be possible anymore if Time is turned into a noinit struct

• The problem is fixed by ensuing explicitness - while still keeping the possibility the to create Time structs.

  Only the unix field is turned into a private field. Not being able to init it with other fields resolves their interferes. Accessing and explicitly setting the unix field is possible via unix() function and method. This approach should provide a better predictable result and more general flexibility in comparison to a @[noinit] solution.

• The next change is making sure that the unix time is present or calculated when a time is used.

• Unix methods have been updated in the go spirit. Former methods have been deprecatd.

  `unix_time` -> `unix`
  `unix_time_milli` -> `unix_milli`
  

While initially planned making it into a v fmt autofix, types of selector expressions are not parsed and not accessible via vfmt. Therefore I'm making the access of a .unix file into a checker warning, informing that it'll become an error and recommending to use unix() instead.

ref. https://discord.com/channels/592103645835821068/592320321995014154/1229503437029380107

[ttytm]

@JalonSolov it was a bit suboptimal with the last PR. Please go ahead here 👍

[JalonSolov]

Should still work without the () since it's in the same module... correct?

[ttytm]

Yes, correct

[ttytm]

But we can keep it here then it calls the function to ensure a unix time is present or calculated if it isn't. So we don't need to wrap it in new() / new_time.

[JalonSolov]

Would it make sense, then, to change the other t.unix to t.unix()?

[ttytm]

Where we can't be sure if an expression has a unix time, this definitively makes sense.

I hope that I applied it now everywhere where it is required to ensure robustness for all cases and only left where internal direct access makes total sense (e.g. when using an internal variable has a now() time value - which certainly will have the unix time on it).