We are currently rewritting the core of our services, basically we have scheduled tasks that can run on intervals, dates, specific times etc etc etc.
Currently we're wondering if daylightsaving might cause trouble for us, basically we calculate the next possible runtime, based on what days the task should execute and between what times, and what interval. We do this by taking the current time, and adding days/minutes/hours to this DateTime.
We then take this new run time and subtract DateTime.Now from this DateTime, leaving us with the timespan untill the next run.
How ever, what if the current time is 01:50 on a daylightsavings day, we add 20 minutes, which is our set interval, and end up with a time of 02:10, how ever since this is daylightsavinds, it's actually 01:10.
When i subtract the current time (01:50) from the 01:10 (which is actually 02:10) does this return a negative value which i need to work around or does this never ever return a negative value because DateTime is just a long underneath holding the proper information?
Basically, the following code, is the check needed or not?
//Get interval between nextrun and right now!
double interval = (NextRun - DateTime.Now).TotalMilliseconds;
//Check if interval is ever less or equal to 0, should never happen but maybe with daylight saving time?
if(interval <= 0)
{
//Set default value
interval = IntervalInMilliseconds;
}
We believe that this check isn't needed but our googling so far hasn't given us a definative answer.
Use DateTime.UtcNow instead of DateTime.Now EVERYWHERE
First of all, you can try it yourself as it will help you understand how it works.
Essentially, using your example above, if you have 20 minutes to a local time, it would be 2:10 and not 1:10 as the computation is done in local time. If you want to get 1:10, you need to convert local time to universal time, add 20 minutes and then convert back to local time.
If you want real elapsed time, then you have to convert time to universal time before computing time difference. Also, if you work in local time, you won't be able to differentiate ambiguous time when the clock goes back.
Related
I've read a few posts about similar subjects but nothing seems to answer this question. My database has the following information about a time
Day of the week (a number between 0-6)
Time (a number of milliseconds since midnight in the users local time)
UTC offset ( number of hours different to UTC )
DST Observed (boolean stating if DST is observed in that time zone)
This data represents opening hours. So there is a time for each day. I want to display that time in the users local time making the assumption that each day is in the future
int dayOffset = availability.Day - (int)now.DayOfWeek
if (dayOffset < 0)
dayOffset += 7;
I'm really struggling to get my head around time zones and handling when one time zone might be observing DST while another maybe DOES observe DST but hasn't yet.
My main issue at the moment is I think I need to create a DateTimeOffset object for the non-local time but I'm not sure how to do that as I don't know if DST is in effect or not.
I hope I'm making myself clear. It really is a mind-bending experience working with dates and time!
As indicated by other answers, the usual solution to handling DateTime across time zones would be to store UTC times.
However, considering that you are not referencing an absolute time at a specific date, but instead are referring to a time at an infinite number of days in a specific time zone; storing the time as an UTC time doesn't make sense anymore, since the UTC time (even if we discard the date) would be different depending on the date, due to DST.
The best way to store the time is fairly close to what you have done already.
Your problem is that the time zone information you are storing at the moment is ambiguous, as it does not refer to a specific time zone, but instead refers to properties of the time zone.
To solve this problem, simply store the time zone identifier instead of the UTC offset and DST boolean.
It is now possible for us to construct the DateTime object and convert it to any time zone by using the TimeZoneInfo class:
int dayOffset = availability.Day - (int)DateTime.Today.DayOfWeek;
if (dayOffset < 0)
{
dayOffset += 7;
}
var openingHourStart = DateTime
.SpecifyKind(DateTime.Today, DateTimeKind.Unspecified)
.AddDays(dayOffset)
.AddMilliseconds(availability.Time);
var sourceTimeZone = TimeZoneInfo.FindSystemTimeZoneById(availability.TimeZoneId);
var userTimeZone = TimeZoneInfo.Local;
var convertedOpeningHourStart = TimeZoneInfo.ConvertTime(openingHourStart,
sourceTimeZone,
userTimeZone);
Give a try to Quartz.NET.
It implements evaluation of CronExpressions, and even triggers to fire events at the given time. It can evaluate the next time an event will occur. This may help you out calculating the opening times.
Also, take a look at the cronmaker website: there you can understand the full potential of CronExpressions.
The CronExpressionDescriptor is a DotNET library for transforming CronExpressions into human readable strings.
Another library which I haven't tried yet is [HangFire].(https://www.hangfire.io/)
In this forum post you can find some discussion on how HangFire implements evaluation of RecurringJobs in local timezone with DST, which I believe is a solution for what you are looking for.
A comment to another answer made the problem a little bit more clear.
So, first and foremost, do store only UTC in your database. Really.
Now, since you are not interested in the actual dates, since you are storing working schedules that repeat weekly, the date only becomes relevant once you want to present your times - and when you put them in your database.
So let's first see how you get your times into your database correctly. I'm assuming a user will enter times in their own locale.
Make sure you first create a (localised) DateTime consisting of the current date and the given time (from the user), and transform that to a UTC DateTime (you can keep the current date, it doesn't matter):
var utcDateTime = DateTime.Now.Date
.AddHours(userHours)
.AddMinutes(userMinutes)
.ToUniversalTime();
Now when you are presenting these times to the user, simply go the other way:
var userDateTime = DateTime.Now.Date
.AddHours(utcDateTime.Hour)
.AddMinutes(utcDateTime.Minute)
.ToLocalTime();
And then you can use the userDateTime.Hour and .Minute for display purposes.
You should be leveraging DateTime.ToLocalTime() and TimeZoneInfo.ConvertTimeToUtc() in C# - see https://msdn.microsoft.com/en-us/library/system.datetime.tolocaltime(v=vs.110).aspx.
If you want to store only times that you're open from Monday to Sunday, fine. Have a simple data table to describe only the time for each day (0 = Sunday through 7 = Saturday -- this is .Net's DayOfWeek enumeration). Your lookup table might look like:
0 null
1 08:00:00
2 08:00:00
3 08:00:00
4 08:30:00
5 08:30:00
6 10:30:00
(Use whatever data type works for you--SQL Server 2008+ has a TIME data type, for example. Null can be used for Closed on that day--i.e., no open time.)
When it comes time to display YOUR time to any other user, use must create your UTC time on-the-fly at the moment you are displaying information to the local user.
Conyc provided one approach. My approach uses simple date/time strings. To use my approach, just store time values per day in your database. Then you can look up the open time for any given day. To express that time for another user in any locale, use this code to convert your time to UTC (you can substitute the "08:00:00 AM" string value with a string variable that you populated after looking up the open time in your database):
var StoreOpenTimeInUtc = TimeZoneInfo.ConvertTimeToUtc(Convert.ToDateTime("08:00:00 AM"));
To look up the open time in your database for a particular day in the future, you will need to concatenate the date to your time value, like this:
var StoreOpenTimeInUtc = TimeZoneInfo.ConvertTimeToUtc(Convert.ToDateTime("04/28/2018 08:00:00 AM"));
Once you have an accurate StoreOpenTimeInUtc variable, you can use that as the UTC value on someone else's machine who is anywhere else on planet earth. To convert that UTC value to their local time, use the .NET ToLocalTime() method:
var OpenTimeForLocalUser = StoreOpenTimeInUtc.ToLocalTime();
Note that this approach requires you to store only the open times as shown above. You don't have to worry about dates, local offsets from UTC, or anything else. Just leverage ConvertTimeToUtc() and ToLocalTime() as shown.
I have some timers that read HH:MM:SS from a table to figure out when to run on a daily basis.
For example:
Timer A needs to run every Monday at 13:00:00
Timer B needs to run every Tuesday at 02:00:00
Timer C needs to run every hour
So in my code I figure out what the current time is and then calculate the milliseconds from DateTime.Now() to the next occurrence of when the timer should run. When the timer's Elapsed event has completed, it recalculates when it is supposed to run next. This created a problem over this weekend due to the time change.
Is there a better way to do this? Would DateTime.UtcNow be a better alternative? Maybe convert the time string in the database to a UTC time and then figure out the difference between DateTime.UtcNow() instead of DateTime.Now()?
You can do several things to solve this problem.
One is to use UTC for all your scheduled jobs. That gives you a robust and predictable system without a lot of complications or testing burden. But the jobs that run at 03:00 on Mondays in the summer will run at 02:00 in the winter. If that's OK, the UTC strategy is a good one.
(Testing timezone switchover use cases is a pain, and if you use UTC for everything your test burden is reduced.)
Another is to get serious with your date arithmetic, and be very careful. C#'s DateTime class does a good job of date arithmetic even on changeover dates.
So, let's say you need to run a process once a week on Sunday at 01:30. That's in the nightmare hour in the USA ... it doesn't happen in the spring changeover, and it happens twice in the fall changeover. But you still want the process to run once.
What you do is this: Keep a "next scheduled time" value. Each time you finish running the job, compute the "next scheduled time" value for the next run. This might work like this:
var today = DateTime.Today.AddDays(7); /* midnight a week from now */
TimeSpan runTime = TimeSpan.Parse("01:30");
var nextRun = today + runTime;
Then, save that nextRun DateTime value. Later on you can figure out how long it is until the next run. This is a good way to do that. There are others.
var msUntilNextRun = (nextRun.Ticks - DateTime.Now.Ticks) / 10000;
If the msUntilNextRun value comes up reasonably small and positive, you can sleep until it's time for the run. If it comes up small and negative, you overslept--run immediately (oversleeping is very common).
Adding the days to the present midnight value, then adding the time to that, then figuring how long to wait, is a way to get a reasonable runtime even on changeover days.
First of all, sorry about my ignorance and my awful english skills, i work to improve them.So here goes my question:
I want use DateTime.Ticks (instead Guid.NewGuid) in order to calculate an identifier and a question is being raised to me. In my current culture we have 2 days on the year when we change the official time: in octuber we add an hour and in april we remove it.
how does it affect to the ticks value? how ticks value is calulated? As far as i understand based on https://msdn.microsoft.com/en-us/library/system.datetime.ticks%28v=vs.110%29.aspx it seems it is not able to be a repeat value because based on the text (...)It does not include the number of ticks that are attributable to leap seconds(...) .
there could be repeated ticks?, (maybe other question would be how long a tick lasts, depends on the computer? )
If i'm not wrong it cant be repeated.
Moreover, Maybe there could be a lot of stuff i misunderstand so i'm really sorry again...
Even without DST changes, you can observe DateTime.Now.Ticks returning the same value multiple times, due to the granularity of the system clock.
But with DST changing, if you use DateTime.Now, you will indeed see the same values repeating for one hour per year. The Ticks property is just "the number of ticks since the DateTime epoch, in whatever kind of value is represented". (A DateTime value can be one of three "kinds" - universal, local, or unspecified. It's all a bit of a mess.)
If you use DateTime.UtcNow you shouldn't see that if your system clock only moves forward... but it's entirely possible for system clocks to be changed, either manually or in an automated way, to correct them for drift. Basically, it's not a good source of uniqueness on its own.
(In terms of the length of a tick - the tick in DateTime is always 100ns. That's not true for Stopwatch, where you need to use the Frequency property to find out how long a tick is, or use the Elapsed property to just find the elapsed time as a TimeSpan.)
Hi have an application offering a 30 days trial. When installed, I am adding a registry key with the current DateTime.Now value.
installDate = DateTime.Now;
RegistryKey regKeyAppRoot = Registry.CurrentUser.CreateSubKey(registryKeyPath);
regKeyAppRoot.SetValue("InstallDate", installDate);
Whenever the application is started, I load the value from the registry and compare it to the current DateTime.Now value again and obviously depending on the result of the comparison I show appropriate messages.
RegistryKey regKeyAppRoot = Registry.CurrentUser.CreateSubKey(registryKeyPath);
installDate = (DateTime)regKeyAppRoot.GetValue("InstallDate");
if (installDate.AddDays(30) > DateTime.Now)
; //MessageBox.Show(...)
My problem is that a simple change of the system time (to the past) would just allow the usage of the application again as the condition will no longer be met. That is explicable as the DateTime.Now property gets a DateTime object that is set to the current date and time on this computer, expressed as the local time.
How can I escape that and get the exact number of days since when my application was installed?
You could save the date of the last check and compare the current date. If they are on different days, then increment a counter. In this way the user has "at most" 30 day uses.
So...
DateTime lastCheck = ... // Recover it from the registry
DateTime now = DateTime.Now.Date;
if (now != lastCheck.Date)
{
UsesCounter++;
}
lastCheck = now;
I'll add that normally it's a little better to use UtcNow, not Now, in this way you are safe from Daylight Time changes.
Another option is to use an Internet clock :-) There are many sites that give the exact time (this option is good only if your program normally connect to Internet)
One simple approach would be to save the date and time each time the program is started and quit. The next start compares the current date and time to the saved one. If it is less than the saved one, your application refuses to start.
This certainly wouldn't completely remove that problem, but it would make it harder for the user, because he would need to know what date and time he needs to set his computer to.
If you save time, when your application ended, you can check that current time is greater than ended time
In C#
DateTime dateAndTime = DateTime.Now;
gives the current date and time. I need only the current time. If I use string, it is possible like:
string time=DateTime.Now.ToString("hh:mm:ss");
Is it possible to get only the time portion of DateTime without going through a string?
You can get the current time in a TimeSpan by accessing TimeOfDay, like this:
TimeSpan time = DateTime.Now.TimeOfDay;
Now time will represent the amount of time that passed since midnight.
There is no out-of-the-box type that holds just a time. You could use TimeSpan, and even the .NET framework does at parts (for example DateTime.TimeOfDay), however I think that TimeSpan is really serving a different purpose.
TimeSpan, to quote MSDN, simply "measures a time interval". That could easily be longer than the hours, minutes, seconds, etc. that make up a day (i.e. 24 hours in sum). And indeed the TimeSpan structure provides for that, having properties like Days, for example.
Thus, I think TimeSpan is not a very good fit to represent the time of day (which I assume you mean when saying "current time").
That brings us to another problem. What exactly is the "current time"? As I said, I assume that you mean the current time as in "the current time of day". But current time could also mean the current (elapsed) time since some particular point in time in the past.
Granted, all that can get pretty theoretic or even rhetoric and does not really help you.
I would just use DateTime. Where you actually care about the "time" value, just only use the time portion (like you have shown, you known about, with your ToString example). Although, depending on what you need the time for, you might resort to the DateTime.TimeOfDay property instead of simply formatting it as a string (unless of course that is what you need).
Finally, you could also resort to third party libraries like Node Time, that do provide types for time only (like LocalTime).
string time = string.Format("{0:hh-mm-ss-tt}", DateTime.Now);