The DateTime.Now
returns the time set on the server and the DateTime.UtcNow
returns the time in UTC which is the "Coordinated Universal Time", in case we have 3 hours difference precisely because you are running on your machine that is in Brazil and most Brazilian states have as time zone "-3 o'clock", on the map on the Wikpedia link you can see the states of Brazil with different hours:
If you set up your computer to use the Acre state time zone you would probably see a difference of -5 hours from the DateTime.UtcNow
.
Already using the method:
Console.WriteLine( DateTimeOffset.Now.ToUnixTimeMilliseconds() );
Or:
Console.WriteLine( DateTimeOffset.UtcNow.ToUnixTimeMilliseconds() );
You will get equal results, because the method ToUnixTimeMilliseconds
works with UTC as well, ie the Unix Epoch is based on UTC so the class internally probably compensates for the "time zone"
Imagine you have two individuals:
- Paulo in Acre (-5 hours in relation to UTC)
- Sofia in São Paulo (-3 hours in relation to UTC)
Paul sends a message to Sophia 18:01
(time in Acre):
I finished the prototype of the app, follow the link to test - Time: 18:01
Sofia will see it in almost the same moment it was sent, but for her it will be 20:01
and will respond back 30 minutes later:
Thanks Paul, I tested the app, it seems that this within the agreed, I await the publication in the store - Time: 20:31
João will receive the message at the same time, but he will view the message as his local time 18:31
:
Thanks Paul, I tested the app, it seems that this within the agreed, I await the publication in the store - Time: 18:31
That is, if saving in the "bank" the time with the Timezone of the person would probably give problems, now if using in its hypothetical bank UTC without applying the Timezone, whether with Unix-time or by the bank itself ai it is sufficient at the time of reading the application to identify the user’s Timezone that is reading the message and adjust the value entered in the bank for its region.
@Matheusmiranda Timetable uses UTC, came out of this only gives a headache. There are some cases that is no problem. Local time should only be used as marking representation and not as time point as it is, time always depends on the context of the reader. Using time is hard enough, hard enough, using wrong is always a problem. It is even common for language libs to be bad and those who want to do everything right have to use something external.
– Maniero
Thank you @Maniero and @Guilhermenascimento is because you are now saving as
DateTime.Now()
in the person’s database and status. The problem is at the time of show to client, so I must make Timezone calculate before showing the client screen or better get current Timezone through the client browser. I’m sure ?– Matheus Miranda
@Guilhermenascimento your little story is a magnificent :)
– Matheus Miranda
@Matheusmiranda is what I said, are very wrong, your case is the most obvious to only use UTC, never anything else. Actually, it has other implications, but I don’t even know your entire case. What I’m going to repeat: almost everyone uses hours the wrong way and gets into complications that you can’t imagine or understand, unless the use is very basic.
– Maniero
very good, I would only change "time set on server", this does not proceed in local applications =]
– Rovann Linhalis
@Maniero in C# has a way of knowing if Datetime.Utcnow is summer or winter ?
– Matheus Miranda
@Matheusmiranda No, it’s universal, there’s no such thing as universal time, this is local time. Like I said, tinkering with hours is very difficult, there’s a lot of detail.
– Maniero
https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-abouttime and https://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-abouttime and ñ is everything.
– Maniero