I have a canvasjs-line-chart, which is filled automatically by PHP (http://jsfiddle.net/9geLc/3).
What I want is the following:
23:00 (11pm) - yValue
0:00 (12pm) - yValue
1:00 (1am) - yValue
But canvasjs sorts like this(although I give the x & y values in the right order):
0:00
1:00
23:00
That makes sense (because 11 pm is after 1am). But 23:00 is from the first day and 0:00 and 1:00 from the second day. So 0:00 and 1:00 have to appear (in the chart) after 23:00. Are there any methods to force the order? Or to set the auto-order to off (maybe auto-order: false or something else)?
Thanks for advice,
Max
Assign the values (23:00 0:00 & 1:00) along with their date and it should automatically work fine. What you are probably doing is setting these hours to the same date
Related
I have to schedule a flow Bi-weekly for monday & friday for every hour.
0 11 * ? * 2,6
But the issue I am having is in timezone , i want the same in IST while it is running in UTC.
I guess there's an option to change timestamp in Bootstrap.conf file but i have many other flows which are running as per UTC scheduling.
Can anyone tell me any feasible solution as I am blocked.
#Ashu
This is a very edge type use case, when conflicting with other flows. Can you not determine the correct time in UTC?
Another idea I have used in the past: if you cannot control the flow in nifi, perhaps you can rethink the trigger method for starting the flow. For example: instead of start of flow from starting processor on cron, make the flow always on but started by trigger on existence of a file (List/fetch File). Then use a separate method outside of nifi to create that file at the time that you want. Now Nifi will only kick off the flow when the file exists.
You can schedule the job as 30 00 * ? * 2,6 , as per UTC Timezone.
which would run every 1 hour monday and friday.
2020-10-23 Fri 00:00:30
2020-10-23 Fri 01:00:30
2020-10-23 Fri 02:00:30
2020-10-23 Fri 03:00:30
2020-10-23 Fri 04:00:30
01AM UTC is 5:30AM IST, which will run your workflow from 5:30AM IST every hour
I am laying bets through the Betfair API and noticed something very strange. For some events the time is off on both market and event results.
My account date and time are set to Europe/London. Not that it matters, the API outputs whatever zone it wants anyway, apparently at random (sometimes GMT other times London or whatever other timezone, but the ISO timestamp does not include +0100 or whatever GMT offset), all this despite the fact that my account is set to EU/London.
For example let's take this event Superettan / Jonkopings Sodra v Varnamo
The API output is:
{"event"=>{"id"=>"28836884",
"name"=>"Jonkopings Sodra v Varnamo", "countryCode"=>"SE",
"timezone"=>"GMT", "openDate"=>"2018-08-13T18:00:00.000Z"
}, "marketCount"=>2}
Their website however says the event starts at 17:00 GMT / 18:00 London (now GMT+1).
There are hundreds examples like this. Cannot get anything out of Betfair support, they take days/weeks to reply and when they do they just send some canned message.
Has someone seen this issue before? Or perhaps I am missing something?
Later edit: I had to dump all their market data to reach this conclusion: it appears that when their API says the timezone is GMT the event is actually on London, so GMT+1 right now, and for every other timezone (Eu/London, Perth, US...) the time is actually on GMT. Not sure what's up with that. Still investigating.
All times returned by Betfair are in UTC - that's just the way the API works. They also supply time zones which may or may not be correct. Use the time zones as an indication of the local time of the event. However, the time zones are very "hit and miss", so don't rely on them to be correct. In fact, over time you will notice lots of "data errors" for non-pricing info on Betfair markets. This is just the way it goes. so don't expect them to fix the errors
Event.openDate is documented as "The scheduled start date and time of the event. This is Europe/London (GMT) by default" while Event.timezone is defined as "[the] timezone in which the event is taking place."
So, in one sense, the openDate in your API output is correct because it says 18:00. However, it's incorrect because it includes the Zulu 'Z' suffix indicating GMT / UTC. The inclusion of 'GMT' in the timezone field: a) is wrong; and b) just serves to confuse matters, IMHO.
Instead, I've started to use MarketCatalogue.marketStartTime which is defined as "The time this market starts at..." which isn't quite the same as openDate but, if they're going to be different, usually on Betfair you're more interested in when the market goes in-play than when the actual match / race / game begins.
The Events I'm using to validate this approach seem to work better this way. Bearing in mind that the UK moves from BST on 27 October to GMT on 28 October, from the API I'm receiving these as MarketCatalogue.marketStartTime:
Liverpool v Cardiff: "2018-10-27T14:00:00.000Z" [Correct: 14:00 GMT is 15:00 BST]
F1 Mexico Grand Prix [qualifying]: "2018-10-27T18:00:00.000Z" [Correct: 18:00 BST is 19:00 GMT]
Burnley v Chelsea: "2018-10-28T13:30:00.000Z" [Correct: 13:30 GMT is 13:30 GMT]
I want to get the current hour of the week in which day starts from Sunday.
Consider current time is
Time.now
=> 2014-10-29 12:09:23PM +0530
The result should be : 84
Explanation:
Sunday - 24 hours
Monday - 24 hours
Tuesday - 24hours
Wednesday - 12 hours
Total: 84
How can get the user hour of the week. Is there any method available in Ruby ? Or how to do it without Ruby method.
You can get the day of the week and hour of the day using Time#wday and Time#hour.
Time.now.wday
#=> 3
Time.now.hour
#=> 14
The rest is basic mathematics.
Even though I upvoted Yu Hao, I must say it's not a good approach if you want to pay attention to the concerns Jon Skeet raised. To that end, here's another approach:
(Time.now - (Date.today - Date.today.wday).to_time) / 3600
Date.today is, well, today. If you subtract the number of days since the week started, you get Sunday. Convert it to Time and it's the midnight when Sunday began. Subtraction gives you number of seconds between then and now. Divide by 3600 (and optionally round) to get number of hours. The DST details should be transparently handled by Time#-.
EDIT: Timezones... Run this before:
ENV['TZ']='EST5EDT'
(be sure to reset it back to what it used to be afterwards, in case anyone else needs to know time and didn't count on you switching timezones.) You can also use "America/New_York" instead. See tz list for details.
I have field in my table as "start_time" as string. E.g Value is "2014-02-07T02:00:00Z". This is provided by API.
We want to show this time as per the client time zone (May EST, Central, IST, Pacific time). For testing In my system I set time zone as (Estern Time (US&Canada))
I tried
start_at = "2014-02-07T02:00:00Z"
start_time = Time.parse(start_at.chop!)
gm_start_time = Time.gm(start_time.strftime('%Y'), start_time.strftime('%b'), start_time.strftime('%d').to_i, start_time.strftime('%H'), start_time.strftime('%M'), start_time.strftime('%S'))
event_start_time = gm_start_time.localtime.strftime('%m/%d/%Y %H:%M')
Result as:
2014-02-07 02:00:00 -0500 ==> start_time
2014-02-06 21:00:00 -0500 ==> gm_start_time
"02/06/2014 21:00" ==> event_start_time
Here I am trying is
convert the string to Time object
Converting that time to GMT
From GMT trying to find equivalent "loca ltime"
If central time is 2014-02-07T02:00:00Z, then local time should 2014-02-07T03:00:00Z
Why I am getting Feb 6th 21 hours. This is -5 hours from expected result. My timezone also -5 hours.
(Time is 24 hours format)
Anyone have any idea on what I am doing wrong?
I think you have some issues with understanding how to handle the time zones. The Z letter at the end of the timestamp indicates that the time is UTC, so apparently your API provides you the time in UTC. When you remove it by using chop! (note that you could simply use chop anyway), Ruby cannot tell anymore what the time zone is, so it's going to use your local time zone by default (I live in UTC+08:00):
1.9.3-p484 :006 > Time.parse("2014-02-07T02:00:00Z")
=> 2014-02-07 02:00:00 UTC
1.9.3-p484 :007 > Time.parse("2014-02-07T02:00:00")
=> 2014-02-07 02:00:00 +0800
Using Time.gm then becomes unnecessary since you already have the time in UTC (assuming the API always sends you timestamps in UTC).
Also, what you are exactly trying to achieve is a bit confusing because you have at least one typo in your post (unless you're trying to obtain a local time in Europe).
I have a bash script runned every day via cron.
In this bash I want to run some command but only every x day (x is fixed and will be 3, 4 or 5 I don't know at the moment)
I can test if the remainder of the division day of month / x equal 0
day_of_month % x = 0
I will work on a single month but not always between to month, for example months april - may with x = 3
1 2 3 4 5 6 7 8 9 ... 27 28 29 30 31 1 2 3 4 5 6 7 8 9 ... 27 28 29 30
x x x ... x x x x x ... x x
It not a big deal, but is there any other way to do this ?
PS : I don't want to explode my script and make 2 cron jobs (one every day : *, the other evevery x day : */x)
One easy solution would be to use "day of year" instead of day of month. Then there'd be no problem with different month lengths. You'd still get problems at the end of year, of course.
The "day of year" is available via date +%j.
If that is still not acceptable, you can use the seconds since 1970 (date +%s), and divide by days*24*60*60, then use the remainder of that. You'd still get problems with leap seconds, but otherwise it should be correct.
Using cron sounds the like the proper idea actually, because that is what cron is made for.
One idea though to solve your 'across months' problems: don't think in months, instead check whether the time-in-seconds-since-epoch % x*seconds-per-day is 0 ...
I would export a system variable with last date of execution and calculate the interval from it. It wouldn't work after a restart but I assume in this case the interval should be restored.
Have a look at the at command
Using that you can tell a script to call itself at a later date.
From manpage:
For example, to run a job at 4pm three
days from now, you would do at
4pm + 3 days, to run a job at 10:00am on July 31, you would do at
10am
Jul 31 and to run a job at 1am tomorrow, you would do at 1am
tomorrow.
If I had this problem, I would tell cron to run my script once every day, and inside the script I would calculate whether or not work needs to be done. That way, you have full control over it.
For example,
dayno=`date +%d`
let divided=daynum%3
if [ $divided == 0 ] ; then
exit 0
fi
# real work begins here
This script would work on any system that uses bash.
Does your job need to run every day? That is, does it do something on those days when your calculation does not result in a 0. If not, you could set up a job in cron thus:
0 12 3,6,9,12,15,18,21,24,27,30 * * <your job>
and it would run every third day (at 12 noon in my example).
I'm pretty sure that "Feb 30" would be safely ignored.