After some research I read in several places that Apple does not let applications run in backgroud except for some specific categories, but I need a solution and I could not find help in any documentation and / or research.
I have the need to leave an automatic task to occur at 10:45 pm which in the case would be to subtract the existing value in a variable to another variable, a discount calculation basically, however the user can choose which days of the week it will repeat itself , however the schedule it runs will always be at 10:45 pm, would anyone have a solution?
Related
I've been trying to do this for a while but can't find a solution. At work there is a special task that needs to be done daily by different people, on rotating shifts. I am trying to create a simple file in sheets in which you can go and clearly see who should be doing that tasks that day.
The data comes from a schedule that is located within the same file. Every day different people are supposed to do these tasks
So what I am trying to do is basically a formula (s) that will recognize what day is today and present it so everyone knows who is supposed to do those tasks today. This should update itself everyday, taking the data from the database. So if today is Friday 20/08/2022 it will show whatever is on the database for that date. If today is Saturday 21/08/2022 it will update and reflect what the schedule/database has.
Sounds pretty easy but I dont know where to start.
Thanks for your help!
try:
=FILTER(C:G; A:A=TODAY())
I have the following feature on a web app:
For the picture above, I save the time specified on a Schedule model for some work to be performed. At the moment this works perfectly for "Simple" selections meaning that if a user selects Hourly, Weekly, Daily, or Monthly only, then I have a fleet of cron jobs that will start Hourly, Weekly, Daily, or Monthly. So just to be clear, I have 4 cron jobs already placed in my crontab that will run at the specified time and pick the corresponding schedule models.
The problem that I'm facing is the Custom feature. I'm stumped as to how I can effectively create a background task to run on custom input for a user. Here is an example scenario. Let's say I have 3 users who each select a custom time to perform some work.
User 1 selects a custom task to be done on January, February, and March only.
User 2 selects a custom task to be done on Mondays at 1, 3, 6, and 9 pm.
User 3 selects a scan to be done on Friday through Saturday every month only.
And the customization goes on and on.......
What would be an effective and feasible way of implementing this kind of behavior? For the moment, I'm stumped and haven't come up with a way to even approach this based on the requirement. From what I have read, I believe a delayed job will help me based on this stack overflow question custom job based on input but with so much variability, how would this be possible. Some help and guidance would be appreciated. Thank you.
I'd probably go with a mechanism that enqueues the job once for the next occurrence when the configuration is saved. Then, after it has been run, calculate the next occurrence and so on. Don't forget to first remove the already-scheduled run when making changes to the configuration. This can be tricky with some ActiveJob adapters which is why, in case you haven't made a decision towards a specific one yet, I'd like to recommend que. But you can do it in Sidekiq, too.
To facilitate calculation of the next occurrence, you could use, for example, the ice_cube gem.
First-time caller, long-time listener. I'm sorry if the title is a bit off, not really sure how to vocalize this issue. I have built a system at work for our work-study students to clock-in on. Unfortunately, the rest of our University is on a paper system and I cannot accept that. The system is made from two parts. The first part is a Google form where clock-in information is reported, it also includes a filter that separates that information based on pay period. The second is another sheet that imports that data and formats it into a printable timecard.
Here is the problem in a nutshell. We have students that work past midnight, potentially to 2:00 am. I need this system (or some system) to clock them out at midnight and clock them back in on the following day at 12:00 am.
Not even sure where to start with this one. I guess I need a script? A solution, advice or just a point in the right direction would be greatly appreciated. Thanks for your time all!
Form & Filter:
https://docs.google.com/spreadsheets/d/19LfKUQY6etiRY2wuyFYM8Jzay7IGXrwn0rHKgDwnmE4/edit?usp=sharing
Pay info and Timecard format:
https://docs.google.com/spreadsheets/d/1-2-7D7AHi6J-4cURlOsQOC1KznCR6zsejkTbyBFamjA/edit?usp=sharing
It sounds like a cool project! Here are some thoughts:
Using the Script Editor at Tools > Script Editor in Google Sheets:
You can collect the clock in and clock out timestamps.
You go through those cells in the code and if the day is different in between Clock in and Clock out, we know the student worked overnight. Now you do this:
You take the clock in time and make the clock out time midnight on that day.
You insert a new row after the Clock in row (sheet.insertRow()), and then in the new row you set the Clock In time to 0AM and the Clock Out time to the departure time.
I imagine people have already done this before and faced your same problem, so here are some examples I found online, although they may not address your specific issue:
https://bazroberts.wordpress.com/2017/03/06/apps-script-clocking-in-out-system/
You may be able to find a Google Sheets add-on for this - I see a couple on the store: https://docs.google.com/spreadsheets/create?addon_store
This might point you in the right direction. I check for a PM followed by AM. If it finds this condition, it splits it into two calculations. One up to midnight and the other on for after midnight. The next day looks back and if after midnight time occurs it picks it up. If no after midnight time occurs, it does what you do now. I think you can make this work (you will need to add a couple of columns which you can hide). I don't know what you would do on the last day of your time card. Below is an example you can copy:
https://docs.google.com/spreadsheets/d/1cO1ggY05kz70lfPE0YZCXaaa0AiaGKDM1s9FQPnw6Zs/edit?usp=sharing
We have a Quartz.NET cron trigger setup that needs to execute a job using the following schedule:
At 02:00hrs in the merchants time zone daily
However, when Daylight Savings Time (DST) occurs abnormalities occur i.e:
When the merchants timezone moves from +2 GMT to +3 GMT, the job does not get executed.
When the merchants timezone moves from +3 GMT to +2 GMT, the job does gets executed twice.
We already know that this behaviour is by design (http://www.quartz-scheduler.net/faq.html#daylight) but what are people using as a solution to this DST issue?
Cheers
Billy Stack
The link you point to may have been updated in the three years or so (!) since you asked this question. It would appear that the job should not be executed twice.
I'm unsure whether 02:00 officially 'occurs' in the US when daylight savings starts, so the concern about the job skipping execution at 02:00 could be resolved by setting it to 01:59:59 (cron trigger "59 59 1 ? *"), as long as you were in North America. Other countries may change at a different time of night. In Europe, for instance, the change is at 01:00, so there it would be better to set the trigger to 02:00:01
Just experienced the same issue as well, although in my case the trigger was not scheduled to fire between 0:00 and the DST change time (2:00 in the US). Instead, I had a job that runs MON-FRI at 8 in the morning, so it ran twice on the Monday November the 5th, the day following the DST change day.
If you read the FAQ item linked to in the question, it kinda makes sense. The Cron trigger wakes up, fires the job, then calculates next time to wake up. When it woke up on Friday at 8am, it calculated next time to run as Monday at 8am. However, by Monday morning what used to be 8am became 7am, so the trigger fired at that time. And then when it ran, the next time was "correctly" calculated as 8am, so it ran again at that time also.
Hope this helps somebody struggling to understand the issue.
Jobs run twice in the fall and don't run at all in the spring. It doesn't matter what time they are scheduled. The question was and still is, "How do you stop this from happening?" If you manually delete all jobs after the time change and before they run then add them back then it works fine. I haven't looked at it yet but thinking this could be automated. Write something that reads all scheduled jobs and adds them and deletes the old records. Whatever you write would need to run from the Windows job scheduler because it wouldn't run at all in the spring if it ran from Quartz.
I have to write some code working with timezones. Is there a good introduction to the subject to get me started?
Also answered at What every developer should know about time (which includes the referenced screenshots).
With daylight savings time ending today, I thought this was a good time for a post. How to handle time is one of those tricky issues where it is all too easy to get it wrong. So let's dive in. (Note: We learned these lessons when implementing the scheduling system in Windward Reports.)
First off, using UTC (also known as Greenwich Mean Time) is many times not the correct solution. Yet many programmers think if they store everything that way, then they have it covered. (This mistake is why several years ago when Congress changed the start of DST in the U.S. you had to run a hotfix on Outlook for it to adjust reoccurring events.)
So let's start with the key question – what do we mean by time? When a user says they want something to run at 7:00 am, what do they mean? In most cases they mean 7:00 am where they are located – but not always. In some cases, to accurately compare say web server statistics, they want each "day" to end at the same time, unadjusted for DST. At the other end, someone who takes medicine at certain times of the day and has that set in their calendar, will want that to always be on local time so a 3:00pm event is not 3:00am when they have travelled half way around the world.
So we have three main use cases here (there are some others, but they can generally be handled by the following):
1.The same absolute (for lack of a better word) time.
2.The time in a given time zone, shifting when DST goes on/off (including double DST which occurs in some regions).
3.The local time.
The first is trivial to handle – you set it as UTC. By doing this every day of the year will have 24 hours. (Interesting note, UTC only matches the time in Greenwich during standard time. When it is DST there, Greenwich and UTC are not identical.)
The second requires storing a time and a time zone. However, the time zone is the geographical zone, not the present offset (offset is the difference with UTC). In other words, you store "Mountain Time," not "Mountain Standard Time" or "Mountain Daylight Savings Time." So 7:00 am in "Mountain Time" will be 7:00 am in Colorado regardless of the time of year.
The third is similar to the second in that it has a time zone called "Local Time." However, it requires knowing what time zone it is in in order to determine when it occurs.
Outlook now has a means to handle this. Click the Time Zones button:
And you can now set the time zone for each event:
When I have business trips I use this including my flight times departing in one zone and arriving in another. Outlook displays everything in the local timezone and adjusts when that changes. The iPhone on the other hand has no idea this is going on and has everything off when I'm on a trip that is in another timezone (and when you live in Colorado, almost every trip is to another timezone).
Putting it to use
Ok, so how do you handle this? It's actually pretty simple. Every time needs to be stored one of two ways:
1.As UTC. Generally when stored as UTC, you will still set/display it in local time.
2.As a datetime plus a geographical timezone (which can be "local time").
Now the trick is knowing which to use. Here are some general rules. You will need to figure this out for additional use cases, but most do fall in to these categories.
1.When something happened – UTC. This is a singular event and regardless of how the user wants it displayed, when it occurred is unchangeable.
2.When the user selects a timezone of UTC – UTC.
3.An event in the future where the user wants it to occur in a timezone – datetime plus a timezone. Now it might be safe to use UTC if it will occur in the next several months (changing timezones generally have that much warning - although sometimes it's just 8 days), but at some point out you need to do this, so you should do it for all cases. In this case you display what you stored.
4.For a scheduled event, when it will next happen – UTC. This is a performance requirement where you want to be able to get all "next events" where their runtime is before now. Much faster to search against dates than recalculate each one. However, this does need to recalculate all scheduled events regularly in case the rules have changed for an event that runs every quarter.
1.For events that are on "local time" the recalculation should occur anytime the user's timezone changes. And if an event is skipped in the change, it needs to occur immediately.
.NET DateTime
Diving in to .NET, this means we need to be able to get two things which the standard library does not provide:
1.Create a DateTime in any timezone (DateTime only supports your local timezone and UTC).
2.For a given Date, Time, and geographical timezone, get the UTC time. This needs to adjust based on the DST rules for that zone on that date.
Fortunately there's a solution to this. We have open sourced out extensions to the DateTime timezone functionality. You can download WindwardTimeZone here. This uses registry settings in Windows to perform all calculations for each zone and therefore should remain up to date.
Browser pain
The one thing we have not figured out is how to know a user's location if they are using a browser to hit our web application. For most countries the locale can be used to determine the timezone – but not for the U.S. (6 zones), Canada, or Russia (11 zones). So you have to ask a user to set their timezone – and to change it when they travel. If anyone knows of a solution to this, please let me know.
Update: I received the following from Justin Bonnar (thank you):
document.getElementById('timezone_offset').value = new Date().getTimezoneOffset();
Using that plus the suggestion of the geo location for the IP address mentioned below will get you close. But it's not 100%. The time offset does not tell you if you for example if you are in Arizona (they & Hawaii do not observer daylight savings time) vs Pacific/Mountain (depending on DST) time zone. You also depend on javascript being on although that is true for 99% of the users out there today.
The geo location based on IP address is also iffy. I was at a hotel in D.C. when I got a report of our demo download form having a problem. We pre-populate the form with city, state, & country based on the geo of the IP address. It said I was in Cleveland, OH. So again, usually right but not always.
My take is we can use the offset, and for cases where there are multiple timezones with that offset (on that given day), follow up with the geo of the IP address. But I sure wish the powers that be would add a tz= to the header info sent with an HTML request.