-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
time: update unix time acces, fix issues related to deviating unix times #21293
Conversation
@JalonSolov it was a bit suboptimal with the last PR. Please go ahead here 👍 |
return t.unix | ||
return t.unix() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should still work without the ()
since it's in the same module... correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, correct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense, then, to change the other t.unix
to t.unix()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
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: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 theunix
field is possible viaunix()
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.
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 useunix()
instead.ref. https://discord.com/channels/592103645835821068/592320321995014154/1229503437029380107