I have some problem with comparing to dates in Parse Cloud Code using moments.js
I'm sending new ETA of a client and compare it with the ETA saved in server.
The time in client looks fine, but when i send it to Cloud Code i changed by 2 hours.
Here is the log of my Cloud Code:
Set ETA at first time:
Input: {"orderID":"S9Aztq5Hky","userETA":"20:27"}
ETA Update Log (The comparison made here):
I2016-01-10T18:15:03.913Z]User New ETA: Sunday, January 10th 2016, 6:15:03 pm GMT+0000
I2016-01-10T18:15:05.873Z]User Current ETA Value: Sunday, January 10th 2016, 8:27:46 pm GMT+0000
What do I miss?
Why does the time change?
Thanks.
Related
I am looking to create a microsoft flow to check if an email was received between 18:00 and 18:15 Pacific Time. Ideally this would be a single formula instead of comparing time >= 18:00 and time <= 18:15
Currently I have:
convertTimeZone(triggerOutputs()?['body/receivedDateTime'], 'UTC', 'Pacific Standard Time', 'HH:mm')
to convert the datetime from UTC to PST in HH:mm format. My next thought was to subtract a time (18:00) from this and get the difference in minutes, then checking that this value is between 0 and 15
I've broken out my answer but you can do what you need with it. Personally, I think this is the most transparent and easiest approach but it's up to you.
Flow
To break it down ...
Firstly, the first step is me merely initialising a string that can be used to get the time from.
Next, I transform the minutes into an integer using the following expression (change out the locale as needed) ...
int(formatDateTime(parseDateTime(variables('Received DateTime'), 'en-AU', 'yyyy-MM-dd HH:mm'), 'HHmm'))
Finally, I do the comparison using this expression ...
and(greaterOrEquals(variables('Time Integer'), 1800), lessOrEquals(variables('Time Integer'), 1815))
Invalid
Valid
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 have a lists of system logs in a log file ,in which I have to calculate time difference between two particular logs based on some condition
#timestamp message
May 19th 2016, 02:55:29.003 just some log
May 19th 2016, 02:55:29.003 retired 2 times
May 19th 2016, 02:55:29.200 System1 down -------
May 19th 2016, 02:55:29.205 just some log
May 19th 2016, 02:55:29.453 System1 up ----
May 19th 2016, 02:55:39.200 System2 down
May 19th 2016, 02:55:49.205 just some log
May 19th 2016, 02:55:53.453 System2 up -------
May 19th 2016, 02:55:58.453 all done
For example in the mentioned log, we need to trigger the calculation when we see the message 'retried' in some log.
On seeing the message it should start the calculating the difference from immediately followed message which contains 'System1 Down' message till it sees the 'System1 Up' message.But here the issue is that the system message can be dynamic like either 'System1' or 'System2'
If it starts with 'System1 Up' , it should calculate time till 'System1 Down'
and same for 'System2 Up'. Is there a possibility to use regex in logstash.
And all the process should stop when it see 'all done' in the message. The time difference calculation should start again if it sees 'retired 2 times' in any of the logs that come below afterwards.
I tired to use elapsed plugin in Logstash and aggregate but not sure, it didn't work for this kinda flow.
What is best to do this? Either in Logstash , elastic search or Kibana.
Thanks in advance
I have a strange issue with the scheduler.
I'm sending a reporting that's always referring to the last day, however the reporting always refers to the day before that day. E.g. on the 2nd of January (time of writing this), it's the 31th of december (it has nothing to do with month / year change).
When I log in to the server, the times seem to be correct:
$ date
Do 2. Jan 08:33:48 UTC 2014
# via python:
>>> import datetime
>>> datetime.datetime.now()
datetime.datetime(2014, 1, 2, 8, 33, 44, 650541)
# the func that calcs the previous day gives the correct day as well
>>> dates.getBeginningOfYesterday().strftime('%d.%m.%Y')
'01.01.2014'
So, basically I'm not able to reproduce the error, but the scheduler keeps sending with this timegap.
My guess is a local time offset causing you to span a day boundary incorrectly. The examples you show are in UTC, but if you're using a localized timestamp for calculations there could easily be a 5+ hour time offset, causing you to be a day earlier.