I need to add decorators that will represent from 6 days ago till now.
how should I do it?
lets say the date is realative 604800000 millis from now and it's absolute is 1427061600000
#-604800000
#1427061600000
#now in millis - 1427061600000
#1427061600000 - now in millis
Is there a difference by using relative or absolute times?
Thanks
#-518400000--1
Will give you data for the last 6 days (or last 144 hours).
I think all you need is to read this.
Basically, you have the choice of #time, which is time since Epoch (your #1427061600000). You can also express it as a negative number, which the system will interpret as NOW - time (your #-604800000). These both work, but they don't give the result you want. Instead of returning all that was added in that time range, it will return a snapshot of your table from 6 days ago....
Although you COULD use that snapshot, eliminate all duplicates between that snapshot and your current table, and then take THOSE results as what was added during your 6 days, you're better off with :
Using time ranges directly, which you cover with your 3rd and 4th lines. I don't know if the order makes a difference, but I've always used #time1-time2 with time1<time2 (in your case, #1427061600000 - now in millis).
Related
I am applying the VRP example of optaplanner with time windows and I get feasible solutions whenever I define time windows in a range of 24 hours (00:00 to 23:59). But I am needing:
Manage long trips, where I know that the duration between leaving the depot to the first visit, or durations between visits, will be more than 24 hours. So currently it does not give me workable solutions, because the TW format is in 24 hour format. It happens that when applying the scoring rule "arrivalAfterDueTime", always the "arrivalTime" is higher than the "dueTime", because the "dueTime" is in a range of (00:00 to 23:59) and the "arrivalTime" is the next day.
I have thought that I should take each TW of each Customer and add more TW to it, one for each day that is planned.
Example, if I am planning a trip for 3 days, then I would have 3 time windows in each Customer. Something like this: if Customer 1 is available from [08:00-10:00], then say it will also be available from [32:00-34:00] and [56:00-58:00] which are the equivalent of the same TW for the following days.
Likewise I handle the times with long, converted to milliseconds.
I don't know if this is the right way, my consultation would be more about some ideas to approach this constraint, maybe you have a similar problematic and any idea for me would be very appreciated.
Sorry for the wording, I am a Spanish speaker. Thank you.
Without having checked the example, handing multiple days shouldn't be complicated. It all depends on how you model your time variable.
For example, you could:
model the time stamps as a long value denoted as seconds since epoch. This is how most of the examples are model if I remember correctly. Note that this is not very human-readable, but is the fastest to compute with
you could use a time data type, e.g. LocalTime, this is a human-readable time format but will work in the 24-hour range and will be slower than using a primitive data type
you could use a date time data tpe, e.g LocalDateTime, this is also human-readable and will work in any time range and will also be slower than using a primitive data type.
I would strongly encourage to not simply map the current day or current hour to a zero value and start counting from there. So, in your example you denote the times as [32:00-34:00]. This makes it appear as you are using the current day midnight as the 0th hour and start counting from there. While you can do this it will affect debugging and maintainability of your code. That is just my general advice, you don't have to follow it.
What I would advise is to have your own domain models and map them to Optaplanner models where you use a long value for any time stamp that is denoted as seconds since epoch.
In Automation Anywhere, the minute system variable ($Minute$) will only return 1 digit if minutes is less than 10. The variable manager doesn't allow for the format to be edited.
Can you please suggest any workarounds? Thanks!
Create a variable and name it $vMinute$.
Using if condition check if the day is less than 10, then add 0 to the left using variable operation.
The same approach can be done for the hour variable as well.
I have a database table where the timestamps are like following:
TIME
85000
91000
171500
171500
how can I transform that into something like
0850
1715
...?
The defined length of this value is always 6, so I need to work with trim (I guess) in order to first identify if the time was before 10:00 or vice versa.
Cutting the value with left or right won't help right away, also, I do not have all sql-commands due to odbc to DB2 on as400.. so that is a bummer as well.
Here is another way that works:
left(digits(timestamp),4)
Note that timestamp is not really a timestamp, but a decimal(6,0) value. This will also work for times like 0015 or 0001 where you would need to concat('000000', timestamp) for your solution to work in the first hour after midnight.
I have managed now, seems to work as wanted:
left(right(concat('0',timestamp),6),4) as formatted_time
I first added a zero at the beginning:
concat('0',timestamp)**
in order to have a length of 6 also for the timestamps smaller than 10:00.
Then I grabbed all six characters from the right
right(concat('0',timestamp),6)
and finally the first 4 characters of this new result
left(right(concat('0',timestamp),6),4)
and got
0600
0945
1315
I am aware that this is not the most elegant or efficient solution. Of course I do appreciate further input.
I want to keep track of opening hours of various shops, but I can't figure out what is the best way to store that.
An intuitive solution would be to have starting and ending time for each day. But that means two attributes per day, which doesn't look nice.
Another approach would be to have a starting time and a day to second interval for each day. But still, that means two attributes.
What is the most commonly and easiest way to represent this? I'm working with oracle.
The lowest granularity you need is probably minutes (actually, probably 15 minute intervals, but call it minutes).
Possibly you also want to consider day of the week.
If you use a table such as:
create table day_of_week_opening_hours(
id integer primary key,
day_of_week integer not null,
store_id integer not null,
opening_minutes_past_midnight integer default 0 not null,
closing_minutes_past_midnight integer default (24*60) not null)
Pop a unique constraint on store_id and day_of_week, and for a given store and day of the week you can find the opening time with:
the_date + (opening_minutes_past_midnight * interval '1 minute')
or ...
the_date + (opening_minutes_past_midnight / (24*60))
Shops that open 24 hours a day could be represented with a special code instead of opening times, in a separate table instead of with special opening and closing times, or maybe you could just leave the opening/closing times null.
create table day_of_week_24_hour_opening(
id integer primary key,
day_of_week integer not null,
store_id integer not null)
Think about shops that do not open at all on a given day as well, and how to represent that.
Probably you could do with a date-based override also, to indicate different (or no) opening hours on certain dates (Xmas, etc).
Quite an interesting problem, this.
I done something similar once and I used NUMBERs:
START_DATE END_DATE
0700 1800
0915 1745
0600 2300
1115 2215
It was easy to use with the plain SQL i.e. with BETWEEN clause.
What if a store has a break?
I think it makes total sense to have two Column One for Open DateTime and One for Close Datetime. Since Once a shop is open it will have to be closed someday/sometime.
My Suggestion
I would Create a separate table for shop Opening/Closing Times. Since everytime A shop is opened it will have a close time value as well so you wont have any unwanted nulls in you second column. to me it makes total sense to have a separate table altogether for shop opening closing times.
Since oracle does not have a date only or time only datatype, you are going to need to use the date datatype which is both date and time. The intuitive solution you mentioned looks pretty good to me.
Your requirements have two data points: an opening time and a closing time. There are different ways of representing the information, but you will need two attributes.
I understand why you think having two attributes will lead to "a longer condition to check" whether "a given time is in the interval". But Oracle provides many ways to manipulate its
DATE datatype. Find out more.
One useful mask is 'SSSSS', which is the number of seconds past midnight. So, if you hold opening and closing times as seconds you can check the interval like this:
select * from shop
where sysdate between trunc(sysdate) + (opening_time_sssss/86400)
and trunc(sysdate) + (closing_time_sssss/86400)
I'm not saying it's elegant but it is effective.
Actually, it would be possible to store the opening hours in a single attribute: by representing them as a bit mask in a RAW column. That would be harder to understand and even less elegant to check.
I have a Ruby on Rails application that uses MySQL and I need to calculate blocks of free (available) time given a table that has rows of start and end datetimes. This needs to be done for a range of dates, so for example, I would need to look for which times are free between May 1 and May 7. I can query the table with the times that are NOT available and use that to remove periods of time between May 1 and May 7. Times in the database are stored at a fidelity of 15 minutes on the quarter hour, meaning all times end at 00, 15, 30 or 45 minutes. There is never a time like 11:16 or 10:01, so no rounding is necessary.
I've thought about creating a hash that has time represented in 15 minute increments and defaulting all of the values to "available" (1), then iterating over an ordered resultset of rows and flipping the values in the hash to 0 for the times that come back from the database. I'm not sure if this is the most efficient way of doing this, and I'm a little concerned about the memory utilization and computational intensity of that approach. This calculation won't happen all the time, but it needs to scale to happening at least a couple hundred times a day. It seems like I would also need to reprocess the entire hash to find the blocks of time that are free after this which seems pretty inefficient.
Any ideas on a better way to do this?
Thanks.
I've done this a couple of ways. First, my assumption is that your table shows appointments, and now you want to get a list of un-booked time, right?
So, the first way I did this was like yours, just a hash of unused times. It's slow and limited and a little wasteful, since I have to re-calculate the hash every time someone needs to know the times that are available.
The next way I did this was borrow an idea from the data warehouse people. I build an attribute table of all time slots that I'm interested in. If you build this kind of table, you may want to put more information in there besides the slot times. You may also include things like whether it's a weekend, which hour of the day it's in, whether it's during regular business hours, whether it's on a holiday, that sort of thing. Then, I have to do a join of all slots between my start and end times and my appointments are null. So, this is a LEFT JOIN, something like:
SELECT *
FROM slots
WHERE ...
LEFT JOIN appointments
WHERE appointments.id IS NULL
That keeps me from having to re-create the hash every time, and it's using the database to do the set operations, something the database is optimized to do.
Also, if you make your slots table a little rich, you can start doing all sorts of queries about not only the available slots you may be after, but also on the kinds of times that tend to get booked, or the kinds of times that tend to always be available, or other interesting questions you might want to answer some day. At the very least, you should keep track of the fields that tell you whether a slot should be one that is being filled or not (like for business hours).
Why not have a flag in the row that indicates this. As time is allocated, flip the flag for every date/time in the appropriate range. For example May 2, 12pm to 1pm, would be marked as not available.
Then it's a simple matter of querying the date range for every row that has the availability flagged set as true.