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

Replaced calls to DateTime.Now with DateTime.UtcNow to be locale agnostic #133

Merged
merged 6 commits into from
May 12, 2018
Merged

Conversation

Sorrien
Copy link
Contributor

@Sorrien Sorrien commented May 11, 2018

The codebase now uses DateTime.UtcNow, instead of DateTime.Now, to be locale agnostic.
Fixes #110

The codebase now uses DateTime.UtcNow, instead of DateTime.Now, to be locale agnostic.
@dnfclas
Copy link

dnfclas commented May 11, 2018

CLA assistant check
All CLA requirements met.

Ivanidzo4ka
Ivanidzo4ka previously approved these changes May 11, 2018
Copy link
Contributor

@Ivanidzo4ka Ivanidzo4ka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@TomFinley
Copy link
Contributor

Thanks so much @Sorrien ! Just requesting @KrzysztofCwalina take a peek to see if it does what he intends. :)

@Ivanidzo4ka Ivanidzo4ka dismissed their stale review May 11, 2018 19:24

revoking review

@Ivanidzo4ka
Copy link
Contributor

https://github.com/dotnet/machinelearning/blob/master/src/Microsoft.ML.Core/Data/DateTime.cs#L204
I think that part need to be changed to dto.UtcDateTime as well.

@Ivanidzo4ka
Copy link
Contributor

Ivanidzo4ka commented May 11, 2018

Thank you @Sorrien


In reply to: 388462991 [](ancestors = 388462991)

Ivanidzo4ka
Ivanidzo4ka previously approved these changes May 11, 2018
Copy link
Contributor

@Ivanidzo4ka Ivanidzo4ka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@Sorrien
Copy link
Contributor Author

Sorrien commented May 11, 2018

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."

@sharwell
Copy link
Member

❔ Is there any way to switch the code to using DateTimeOffset (which is comparable even in different time zones)?

@Ivanidzo4ka
Copy link
Contributor

Ivanidzo4ka commented May 11, 2018

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
.Microsoft.ML.Scenarios.ScenariosTests.TrainAndPredictIrisModelWithStringLabelTest (from MSTestSuite)

Последняя 1 сборка провалились (С Провалилось#588 )
Заняло 0.46 секунд.
добавить описание
Стек вызовов
MESSAGE:
Assert.Equal() Failure
Expected: 1 (rounded from 1)
Actual: 0.99 (rounded from 0.994781792163849)


In reply to: 388466866 [](ancestors = 388466866)

@shauheen
Copy link
Contributor

You can simply trigger the tests by asking the @dotnet-bot to test Windows_NT Release please as a comment.

@Sorrien
Copy link
Contributor Author

Sorrien commented May 11, 2018

@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;
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@Ivanidzo4ka Ivanidzo4ka dismissed their stale review May 11, 2018 20:20

revoking review

@Ivanidzo4ka
Copy link
Contributor

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.
So I'm not sure DateTimeOffset necessary for this PR


In reply to: 388467246 [](ancestors = 388467246)

@Sorrien
Copy link
Contributor Author

Sorrien commented May 11, 2018

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.

@KrzysztofCwalina
Copy link
Member

KrzysztofCwalina commented May 11, 2018

I've done further research into DateTimeOffset. As I understand it, there is no difference between DateTimeOffset.Now.UtcDateTime and DateTime.UtcNow,

@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.

Copy link
Contributor

@Ivanidzo4ka Ivanidzo4ka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@sharwell
Copy link
Member

sharwell commented May 11, 2018

As I understand it, there is no difference between the result of DateTimeOffset.Now.UtcDateTime and DateTime.UtcNow

Ah, I was suggesting the use of DateTimeOffset.UtcNow instead of DateTime.UtcNow, and eliminating the use of DateTime altogether. DateTimeOffset is a type that does not suffer from the usage limitations leading to this pull request. If someone decides to use DateTimeOffset.Now and someone else uses DateTimeOffset.UtcNow, and a third person uses DateTimeOffset.Now from a different time zone than the first, everything will work together automatically.

@@ -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);
Copy link
Contributor

@TomFinley TomFinley May 11, 2018

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@TomFinley TomFinley left a 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);
Copy link
Contributor

@TomFinley TomFinley May 11, 2018

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

Copy link
Contributor Author

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();
Copy link
Contributor

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.)

Copy link
Contributor

@TomFinley TomFinley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@TomFinley TomFinley merged commit 5d03b54 into dotnet:master May 12, 2018
@tarekgh
Copy link
Member

tarekgh commented May 12, 2018

@KrzysztofCwalina

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.

Yes, DateTime,UtcNow is faster than DateTimeOffset.Now.

@Sorrien
Copy link
Contributor Author

Sorrien commented May 12, 2018

Thanks for working with me everyone. I hope to contribute more in the future.

@shauheen
Copy link
Contributor

Thanks @Sorrien for your contribution and working through this PR. We look forward to that as well.

eerhardt pushed a commit to eerhardt/machinelearning that referenced this pull request Jul 27, 2018
…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.
@ghost ghost locked as resolved and limited conversation to collaborators Mar 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants