-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Replaced calls to DateTime.Now with DateTime.UtcNow to be locale agnostic #133
Conversation
The codebase now uses DateTime.UtcNow, instead of DateTime.Now, to be locale agnostic.
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.
Thanks so much @Sorrien ! Just requesting @KrzysztofCwalina take a peek to see if it does what he intends. :) |
https://github.com/dotnet/machinelearning/blob/master/src/Microsoft.ML.Core/Data/DateTime.cs#L204 |
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 I be concerned about the Windows_NT Release? If so, how can I learn more about what went wrong? It says access denied when I click "details." |
❔ Is there any way to switch the code to using |
We apparently have issue which related with random seed and amount of threads in our tests, so it's not problem on your side. I will open issue regarding that, meanwhile, best i can suggest is retrigger build by adding space somewhere. Regression Последняя 1 сборка провалились (С Провалилось#588 ) In reply to: 388466866 [](ancestors = 388466866) |
You can simply trigger the tests by asking the @dotnet-bot to test Windows_NT Release please as a comment. |
@sharwell I am not as familiar with DateTimeOffset but I will look into it. |
DateTime.UtcNow is now DateTimeOffset.Now.UtcDateTime
@@ -164,7 +164,7 @@ public unsafe void SetTreeScores(int idx, double[] scores) | |||
|
|||
private LassoFit GetLassoFit(IChannel ch, int maxAllowedFeaturesPerModel) | |||
{ | |||
DateTime startTime = DateTime.Now; | |||
DateTime startTime = DateTimeOffset.Now.UtcDateTime; |
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.
DateTimeOffset.Now.UtcDateTime [](start = 33, length = 30)
Is there are any difference between DateTimeOffset.Now.UtcDateTime and DateTime.UtcNow? If no, why you prefer DateTimeOffset?
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.
I've done further research into DateTimeOffset. As I understand it, there is no difference between DateTimeOffset.Now.UtcDateTime and DateTime.UtcNow, but you could access more information from DateTimeOffset like the timezone which would be more useful for storing dates for later. As we are using it here I can't find a difference, so I will undo these changes.
As you can see in PR we mostly use DateTime.something to output time stamps and get ticks. To represent datetime internally as part of IDataView we use DvDateTime (see DateTime.cs) and we use DateTimeOffset in it. In reply to: 388467246 [](ancestors = 388467246) |
I've done further research into DateTimeOffset. As I understand it, there is no difference between the result of DateTimeOffset.Now.UtcDateTime and DateTime.UtcNow, but you could access more information from DateTimeOffset like the timezone which would be more useful for storing dates for later. As we are using it here I can't find a difference, so I will undo these changes. |
This reverts commit 0587855.
@tarekgh, is that your understanding as well? I am under the impression that UtcNow would be faster and more reliable as Now will get time zone info. |
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.
Ah, I was suggesting the use of |
@@ -201,7 +201,7 @@ public DvDateTimeZone(SysDateTimeOffset dto) | |||
// Since it is constructed from a SysDateTimeOffset, all the validations should work. | |||
var success = TryValidateOffset(dto.Offset.Ticks, out _offset); | |||
Contracts.Assert(success); | |||
_dateTime = ValidateDate(new DvDateTime(dto.DateTime), ref _offset); | |||
_dateTime = ValidateDate(new DvDateTime(dto.UtcDateTime), ref _offset); |
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.
new DvDateTime(dto.UtcDateTime), ref _offset); [](start = 37, length = 46)
Interesting. I don't know that this is correct, singe this DateTimeZone
exists to encode a local time including a datetime. So I think that this change here might be inappropriate and is in fact introducing data corruption.
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.
Thank you for pointing that out @TomFinley I will revert this change.
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.
🕐
@@ -450,7 +450,7 @@ private LassoFit GetLassoFit(IChannel ch, int maxAllowedFeaturesPerModel) | |||
// First lambda was infinity; fixing it | |||
fit.Lambdas[0] = Math.Exp(2 * Math.Log(fit.Lambdas[1]) - Math.Log(fit.Lambdas[2])); | |||
|
|||
TimeSpan duration = DateTime.Now - startTime; | |||
TimeSpan duration = DateTime.UtcNow - startTime; | |||
ch.Info("Elapsed time for compression: {0}", duration); |
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.
This in particular is a bit weird and doesn't really have an effect I'd think. Probably harmless though, plus UtcNow
is much faster anyway so may as well use it.
Honestly this code here ought to have been using stopwatch. #Closed
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.
You're right, this has no effect. I have added a stopwatch here instead as per your suggestion
…t removed timezone info where it was actually needed
@@ -164,7 +165,8 @@ public unsafe void SetTreeScores(int idx, double[] scores) | |||
|
|||
private LassoFit GetLassoFit(IChannel ch, int maxAllowedFeaturesPerModel) | |||
{ | |||
DateTime startTime = DateTime.Now; | |||
Stopwatch stopWatch = new Stopwatch(); | |||
stopWatch.Start(); |
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.
Just a quick note, not major: Stopwatch.StartNew()
is made to serve this common case where you both want to create and start a stopwatch. (Not a blocking comment to be clear, only if you happen to post another iteration for some other reason anyway.)
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, DateTime,UtcNow is faster than DateTimeOffset.Now. |
Thanks for working with me everyone. I hope to contribute more in the future. |
Thanks @Sorrien for your contribution and working through this PR. We look forward to that as well. |
…stic (dotnet#133) * Removed calls to DateTime.Now The codebase now uses DateTime.UtcNow, instead of DateTime.Now, to be locale agnostic, except in cases where timezone info is actually needed. Also replaced one starttime measurement with stopwatch.
The codebase now uses DateTime.UtcNow, instead of DateTime.Now, to be locale agnostic.
Fixes #110