I use org-mode to clock my work and sometimes I work past midnight for few hours.
So, for example, I clocked time starting 03.06.2013 10pm and ending 04.06.2013 2am.
And org-mode is dividing it at 0am, starting new day. But it would be more convinient for me if that time 0am-2am was recorded for 03.06.2013 instead of 04.06.2013.
So I want to be able to specify at what time (say, 4am) org-mode is deciding the new day has started.
I can use a workaround by shifting timezone for the emacs process, but then I need to keep in mind that all recorded time is shifted... Not very convinient.
See the variable org-extend-today-until, a variable defined in org.el.
Documentation:
The hour when your day really ends. Must be an integer.
This has influence for the following applications:
When switching the agenda to "today". It it is still earlier than
the time given here, the day recognized as TODAY is actually yesterday.
When a date is read from the user and it is still before the time given
here, the current date and time will be assumed to be yesterday, 23:59.
Also, timestamps inserted in capture templates follow this rule.
Related
Some events don't take place at any specific time and instead are meant to be valid for the whole day irrespective of the time zone the user is at.
For the sake of argument, let's say a system sitting on a server (up in the cloud) runs a job at 5 am and imports data from a different system between this run and the last (24 hours ago). The actual user sitting at his desk doesn't know when the job runs, the user only knows that they go to sleep at night, the server crunches all the entries for the day.
The next morning the user wants to see all the entries from yesterday (what ever the job produced) and they go to the app, pull up a calendar input selector and they pick the 5/26/2022 (today being 5/27/2022).
Assuming the developers followed best practices, the client will transform the date into it's UTC version and send it up through an API. Chances are, depending on where the user is located and the server is, there might be a mismatch.
I could send the date up without it being UTC or I could send a UTC date and try to adjust it back to local time so that I could then compare with the date on record (that exists without an actual time zone).
What I am asking is:
What's the more conventional answer to this particular problem?
Is the idea of a date without time or time zone just ridiculous?
Use UNIX Time. It will give you a timestamp that is universal no matter what timezone the user is in. You can then convert it into whatever timezone you want to.
The concern you describe is well solved/addressed by the ISO 8601 dates/time presentation protocol.
All modern software can read/write dates in ISO 8601.
In Unix machines, the correct command is date with option -I
-I[FMT], --iso-8601[=FMT]
output date/time in ISO 8601 format. FMT='date' for date
only (the default), 'hours', 'minutes', 'seconds', or 'ns'
for date and time to the indicated precision. Example:
2006-08-14T02:34:56-06:00
I've currently got this Cron expression that I'm using to trigger a process in UiPath Orchestrator:
0 0 15 21W * ? *
Runs on the closest working day to the 21st of each month at 3pm.
However I need it to run on the next working day at 3pm if the 21st is a non working day.
Tried searching for an answer and nothing quite fit the brief.
I used this website to build my expression (which is a great tool) but it only had an option for 'nearest day' and not next working day given a specific day of month: https://www.freeformatter.com/cron-expression-generator-quartz.html
As you don't need the nearest day, you can't use the functionality of Orchestrator cronjob. I would recommend creating a wrapper process as follows:
Create a new process, let's call it StartJobByCheckingDate
Now create a trigger that starts StartJobByCheckingDate each day at 3pm
So that process is now your manager of your desired process
Now we need to check if it is the 21th day
Here you have different ways to solve it
You could create a DataTable or even a file in the StartJobByCheckingDate process, that contains all the different days where your desired process should be fired (but this is very manual, you might not want to update this every year, so this might not be the smartest but the easiest solution)
The other idea is to check if the current day is the 21th day. If so check if it is Saturday/Sunday (non-working day).
If true: you could now create a empty dummy file somewhere that tracks that the 21th was a non-working day, and the next day you check that file existing, if it exists you check the current day to be a working day, and if so you delete the file again and start your desired process
If false: just start your desired process directly
I think 2. idea would be that best. Sure you have 365 jobs runs/year. But when you keep that helper process smart this will just be seconds.
Another idea instead of using the dummy file, would be to use Entities. Smarter but need some more time to get familiar with.
We have (had) the exact same issue. Since UiPath doesn't offer a feasible solution out of the box, we will work around the restriction using the following strategy: We trigger the actual job daily, considering a custom-built, static NonWorkingDay-list that will just suppress the execution of the robot every day we don't want it to run.
These steps are needed:
Get a list with of all known bank holidays, saturdays and sundays until 2053 or so...
Build a the static exclusion-list using a script that does something like this (pseudocode. I will update the answer once we have actually implemented the solution):
1. get all valid execution dates
loop through every 28th of the month until end of 2053
if the date is in the bankHolidayList then
loop until the next bankDay is found
add it to the list of valid ExecutionDates
else
add the date to the validExecutionDate-list
2. build exclusion-list
loop through every day until end of 2053
if the date is not in the validExecutionDate-list
add it to the exclusionDate-list
Format the csv accordingly and upload it to the orchestrator tenant as a NonWorkingDay-List
Update your trigger to run daily at your desired time, using the uploaded NonWorkDay-Calendar
While the accepted answer will surely work as well, we prefered to go with this approach because having a separate robot that does nothing but executing a UiPath trigger just doesn't seem right to me. With this approach we have no additional code that we potentially need to maintain.
In my oppinion not having a solution for this concern out of the box is a lack of feature that UiPath will (hopefully) fix until end of 2053 ;-)
Cheers
You can configure your trigger to launch oftener, then manage dates at init of your process, but you must set up a list of "holydays" or check in some way.
Also you can use the calendar option of orchestrator (+info)
I've lost track of how many questions & responses I've read while trying to find an answer on this. The ones that sound like they're related often aren't, or else the users are just accused of being confused. (As an example, the first answer here just tells the person asking the question that they don't really mean to be asking what they're asking. Then there's this one. The most upvoted answer here says it's just impossible. Etc., etc., etc.)
I need to be able to take a time--say 9:00 AM--and work with it as 9:00 AM regardless of which timezone my user is in. If a user pulls up this time in a US/Eastern timezone, they should see this value as 9:00 AM. If a user pulls up this time in a US/Pacific timezone, they should see this value as 9:00 AM. I recognize that this is not actually the same moment in time, and I don't need it to be.
To illustrate, let's call the timezone-immune timestamp I'm talking about timezoneImmuneTimestamp, and say that its value should always be 9:00 AM.
Say I'm executing someMomentInUsEasternTimezone.diff(timezoneImmuneTimestamp, 'minutes'), where someMomentInUsEasternTimezone is equal to 10:00AM (EST). The answer I need is 60 minutes.
Now let's add another Moment, someMomentInUsPacificTimezone and say its value is 11:00AM (PST). When I execute someMomentInUsWesternTimezone.diff(timezoneImmuneTimestamp, 'minutes'), the answer I need is 120 minutes.
Has anyone else had this particular problem, and more importantly, solved it?
It sounds like you want to work with only the "wall time" of each moment object. To do that, first create a clone of each moment and set their offsets to zero, as if they were UTC. When doing so, pass true to keep the wall time instead of the same point in actual universal time.
This is described in the docs for the utcOffset function:
The utcOffset function has an optional second parameter which accepts
a boolean value indicating whether to keep the existing time of day.
Passing false (the default) will keep the same instant in Universal Time, but the local time will change.
Passing true will keep the same local time, but at the expense of choosing a different point in Universal Time.
Thus, to get the difference in minutes between momentA and momentB with respect only to wall time:
momentA.clone().utcOffset(0, true).diff(momentB.clone().utcOffset(0, true), 'minutes')
Though missing from the docs, the same argument can be passed to the utc function. So if you prefer, you can shorten it to:
momentA.clone().utc(true).diff(momentB.clone().utc(true), 'minutes')
(Cloning helps the rest of your code by not mutating the original moment objects.)
Also - The Moment team highly recommends only using Moment in legacy/existing code. If you are writing a new application, please try Luxon instead. In Luxon, the setZone function has a keepLocalTime option that does the same thing as I showed in Moment.
There are a few complex habits/tasks that I wish orgmode to handle, and I'm not quite sure how to program them:
A habit that has to be done twice a day, between certain hours (E.g. 8-9 and 18-19).
A habit that has to be done over the weekend (Between Thursday-Saturday).
A task that occurs every 6 months, twice a day between certain hours, for a duration of 21 days total.
Can someone help with adding the right SCHEDULE?
Weekend only habit:
SCHEDULED: <2013-12-13 Fri ++1w/2d>
This will cause it to repeat every Friday (regardless of when completed), and will be late if delayed by more than 2 days after the next notification.
Twice a day habit:
This will most likely have to be created as two separate habits, one for the first timeframe and one for the second.
Bi-annual:
Most likely requires two TODO's as well to allow for the two timeframes. I'm not sure if there's any real way of doing so without using complex diary SEXPs which you would have to create every 6 months (or update the SEXP to match the next 6 month span). Org TODOs/Habits don't usually include an 'end-date' when they repeat.
I'm developing an international software that act as a simple project management software and I'm facing a problem. This problem is about date/hour and time zone.
When a message is sent from one time zone to another time zone I can store the UTC (GMT) time in my database and then have it displayed differently according to the user's time zone. But this can't be done when I only work with date.
If I say a task is due to the 21st of March. Should I consider that this date can be 20 or 22 in some other countries ? What are your advices on this problem ?
Let's say a user in New York sets a due date for a project as "anytime on Monday 26 January". That means "anytime from 0600 Monday 26 January to 0600 Tuesday 27 January" in Brussels and "anytime from 2000 Sunday 25 January to 2000 Monday 26 January" in L.A.
So completing the task at 2100 on Monday 26 is fine in Brussels and N.Y., but too late in L.A.
One possible work around is never just work with the date. If the time is not specified, either set it for 0000 hrs or 2400 hrs on the date specified in the timezone of the user.
The users may have to deal with strange due dates/times, but speaking as someone who used to work internationally, it kinda goes with the territory.
You won't be able to achieve what you are trying to do without storing the exact time. You simply don't have enough information.
When you don't have a time, assume that the time is the end of business in the main locale for the application, then translate that time as you would any other time. An alternative would be assuming end of the business day in local time and adjust that to UTC. Everyone using the application would need to understand whatever default time assumption you make when the time is not specified. Coordinating to the main office may be best in a large enterprise whereas coordinating to local time may be best in highly decentralized environments where the local context is equally important.
If you aren't storing the minutes and seconds you have to assume that the date being entered is the desired date and not to any adjustments for GMT. Just put it in the database as is. The people on the west coast will have to assume that the due date is the same regardless of where you are in the world. If you want to adjust for time zones, you'll have to collect more information, like hour, minutes, and seconds.
The easiest solution would be just to display as the same date for everyone. The deadline would then effectively be midnight in the latest timezone.
Otherwise, decide what the default time of the deadline should be in the timezone the task was created in, e.g. 21st March 17:00 EST or 22nd March 00:00 EST and display that in the local timezone. The timezone difference will then push it into the previous day or next day accordingly for the viewer.
SQL 2008 allows for a Date datatype that does not have any time value associated with it. That allows someone to say I need this done by this Date, but I don't care if it is +/- several hours. If the date selected is 1/1/2009 but it happens on 1/2/2009 at 2AM their time, they probably don't care.
When the user needs something done by a specific date and time, like close of business on 1/1/2009 then you need to store it in a DateTime as UTC and convert it to local time client-side.
This will take much of the complexity out of indicating when something is completed, it'll either be completed near a specific day or by a specific time.
If you have a single instance of a DB, I would store all dates in the datetime timestamp of your DB server. If you are timestamping rows, consider GetDate() in T-SQL or as default value of the timestamped date column. Then you have your single reference point for all times. Consider UTC format there.
Then, all clients accessing the date do their own conversion into "local time" , which can be interpreted by things like : user preferences, date time stamp on client computer, etc.
Without knowing more, it hard to say exactly what the resolution is.
Your solution depends on your application and requirements.
I'd first store UTC + offset in your data structures, so it's easy to display for any timezone.
Most likely if a task or meeting is due at 12pm on 21/March in London then it will occur at 2130 on 21/March in Adelaide (+0930), but that is an application requirement not any sinister timezone related standard.
If you want the ultimate in flexibility, add a flag that can make the even due simultaneously in every timezone or at the same time no matter where you are (staggered) and show the event accordingly.
You might want to store the date in a from that is timezone aware. This will help you in your calculations. SQL Server 2008 for instance supports a datetimeoffset that does precisely this. Alternatively if you're using SQL 2005 with a bit of effort you can write your own SQL CLR data type to support this.