What I want to do is block a user from doing something for 24 hours after they have reached a limit. I have coded the limit part, I just need to know how to block it if it hasn't been 24 hours.
Here is an example on how I want to do it. Update the user's account using a query and set the timestamp (Unix) to that time. Then I don't know how I can get another timestamp of the time they try to do it and check if the new timestamp is 24 hours between the last?
I have medium experience with C# but timestamps is one section I know nothing about with c#. Ss there anyone here that can help or provide a good tutorial? Or an idea on how I can learn more about it. I'm looking for the best way to do this. If Unix timestamps aren't it then please let me know and provide me with a better way if you can.
//Example
if (!CODE_HERE_FOR_NOT_24_HOURS)
{
MessageBox.Show("You have reached your limit for today. Try again tomorow");
return;
}
else
{
//Code here
}
In C#, you'd typically use DateTime.UtcNow, and use a DateTime, not a unix timestamp.
You can always check to see if its been less than 24 hours via:
if (timeStamp > DateTime.UtcNow.AddDays(-1))
{
// It's been less than 24 hours
}
Related
I am trying to build an Alexa skill that asks the user for an arrival time and I am expecting the answer to be in 24 hour format. So the user would say eighteen o five for 18:05.
I am struggling to find a way for Alexa to understand this without forcing the user down the 12 hour route.
Any suggestions welcome.
The AMAZON.TIME slot type is available but, unfortunately, doesn't work like you want.
If you're happy for users to say "six fifteen pm" it will pass a 24H time to your skill.
This might be unconventional, but have you tried
AMAZON.FOUR_DIGIT_NUMBER
If you think about it 24 hour format is also a 4 digit number
I got around this in the end by using just the one custom slot type which takes the whole time in a malformed state. 18:05 comes in as 18o5. I then use a method within my code to tidy that up. Not the most scientific way to do this, but seems to work.
To provide a TRIAL period to my application when the user first runs the application I save the FirstRunTime like this:
string sFirstRunDate = DateTime.Today.ToShortDateString();
saveInfo.saveFirstRun(sFirstRunDate ); // saves as a string to a text file
Now everytime I run the application I want to see if it has been more then 60 days and if so terminate (60-day trial only). How can I do that compare?
string sFirstRunDate = saveInfo.getFirstRun(); // returns the string I saved earlier
DateTime dtFirstRunDate = DateTime.Parse(sFirstRunDate); // makes it a DateTime
DateTime now = DateTime.Today.ToShortDateString(); // why am I doing this?
So how can I take the two dates and compare them to see if it has been more then 60 days or not?
Thanks,
The following should do it:
var elapsed = DateTime.Today.Subtract(dtFirstRunDate);
if (elapsed.TotalDays > 60)
{
// trial expired
}
The advantage of this is when the trial hasn't expired you can tell them how far they are into their trial (using elapsed.TotalDays).
TimeSpan t = DateTime.Now.Subtract(dtFirstRunDate);
if (t.Days > 60)
{
//do something
}
Try
if(DateTime.Parse(sFirstRunDate).AddDays(60) < DateTime.Now) {
// trial has expired
}
This just takes the first run, adds 60 days to it, if the current time is greater than the time first run + 60 days, the trial is over.
All other answers are technically going to work for you, but they are wrong on a larger scale. Please read further.
// why am I doing this?
This tells me that you do not quite grasp the concepts you're trying to apply. Let's go one by one.
string sFirstRunDate = DateTime.Today.ToShortDateString();
There are two problems with that. First the DateTime.Today returns the local date/time. Never ever use local date/time for any kind of calculations because local time is not consistent. Daylight changes, travel through time zones, all affect the local time that is returned by this property. What you should use instead is DateTime.UtcNow.Date to get the current UTC time which is the global clock not affected by any of the aforementioned problems.
Second problem is the ToShortDateString method. It converts the date/time using current culture. Did you know that in other parts of the world, the date is reported as 'DD/MM/YYYY', or 'YYYY-MM-DD'? What will happen if the user changes current locale? To avoid those problems you should use the ToString(CultureInfo.InvariantCulture) method.
The correct code to serialize the first run date is
string sFirstRunDate = DateTime.UtcNow.Date.ToString(CultureInfo.InvariantCulture);
DateTime now = DateTime.Today.ToShortDateString(); // why am I doing this?
To calculate the difference between two dates, first you need to acquire those two dates. The first one would be the saved first run date, and the second would be today. You did the first part by deserializing the first run date into DateTime structure. For the second part you just need the current date, you don't need to serialize it into string. So
DateTime today = DateTime.UtcNow.Date;
Now that you have two dates, you have an array of options on how to actually get the difference. Any of the other answers do that part just fine. I personally like Timothy Walters' answer as it has a nice side effect of giving your the days left for trial. It will look like:
DateTime dtFirstRunDate = DateTime.Parse(saveInfo.getFirstRun());
DateTime today = DateTime.UtcNow.Date;
var elapsed = today.Subtract(dtFirstRunDate);
if (elapsed.TotalDays > 60)
{
// trial expired
}
I'm currently writing a fairly simple app handling opening/closing times of businesses and running into serious difficulties trying to figure out how to properly store the info.
Most of our critical functionality is heavily dependent on getting times absolutely perfect, so obviously I want to get things done the best way possible to start off with!
Additionally, the data will be inputted by users, so if the underlying representation is slightly more complex (e.g. using TimeSpans to account for opening past midnight), this needs to be invisible to the user.
I need to store firstly, the business's opening hours, by day of week, with a timezone associated with them, e.g:
- M: 1000 - 2330
- T: 1000 - 0030
- W: 1900 - 0300
- Th: 2000 - 0300
- F: 2000 - 0800
- Sa: 1000 - 0500
- Su: 1000 - 2300
I'm currently thinking that the best way to store this is using a class like this:
public class OpeningHours
{
ZonedDateTime OpeningTime { get; set; }
Period durationOpen { get; set; }
// TODO: add a method to calculate ClosingTime as a ZonedDateTime
}
However, there's 2 main complications here:
I don't want to store the Year, Month, or Date part of the ZonedDateTime - I just care about the DayOfWeek.
Sure, I could just store each value as the first Monday/Tuesday etc after Jan 1 1970, but this seems hacky and pretty much plain wrong - as the author of NodaTime, very correctly, explains here when talking about the limitations of the BCL DateTime implementation. I also have a feeling this would probably end up with weird quirky bugs if later on we try and do any arithmetic with the dates.
The user is going to have to input the ClosingTime anyway. Client side I suppose I could do something simple like always assume the ClosingTime is the next day if it's before the OpeningTime, but again, it's not perfect, and also doesn't account for places that might be open for more than 24 hours (e.g. supermarkets)
Another thing I've considered is using a table with hours/days and letting people highlight the hours of the week to pick opening times, but you still run into the same problem with only wanting to store the DayOfWeek part of the OpeningTime.
Any suggestions would be appreciated, spending the last 6 hours reading about the hilariously silly ways we humans represent time has burnt me out a bit!
I would strongly consider using LocalTime instead of ZonedDateTime, for a couple of reasons:
You're not trying to represent a single instant in time; these are naturally recurring patterns (there's no associated date)
You're not trying to cope with the situation where the store is in different time zones for different opening hours; you probably want to associate a time zone with each store once, and then you can apply that time zone whenever you want
So I would have something like this (showing just the data members; how you sort out the behaviour is a separate matter):
public class StoreOpeningPeriod
{
IsoDayOfWeek openingDayOfWeek;
LocalTime openingTime;
LocalTime closingTime;
}
Note that this exactly follows your original data as you've shown it, which is always a good sign - you're neither adding nor losing information, and it's presumably in a convenient form.
If the closing time is earlier than the opening time, it's assumed that this crossed midnight - you might want to add a confirmation box for the user if this is relatively uncommon, but it's certainly easy to spot and handle in code.
I know the title might be confusing, but I'm not sure how to word it better....
I'm doing this to get the logs of the current hour:
'TraceSink-'yyyy-MM-dd HH'-Hourly.log'
How can I get the previous hour? i.e.:
'TraceSink-'yyyy-MM-dd (HH-1)'-Hourly.log'
Is there anything possible with time format like that?
EDIT: I don't have access to the C# code but a exe.config where I can change what goes inside.
Like var on DateTime.ToString(var);
Am I asking too much?
Subtract one hour from the date/time and format that.
The answer to your question is no.
The format string only defines the format. It does not have the ability to perform calculation on it (and why would it?)
I don't know why you have this requirement, but I suspect that you may be receiving DateTime objects from a machine in another time zone... it could be helpful if you included the offset from UTC in your format string:
http://msdn.microsoft.com/en-us/library/8kb3ddd4.aspx#zSpecifier
This way, when you see the log you can tell that the specific event occurred at UTC -3 hours.
I think that's the best you can do without access to the original code.
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.