I am building a GraphQL server with Node, Express and Apollo. I use Postgres for my database. I have a table called tasks in my database and a column called dueDate with the type timestamp. I have a GraphQL type in my server that looks like this:
type Task {
id: String!
...
dueDate: String
createdAt: String!
updatedAt: String!
}
As you can see, I've declared dueDate as a String. I have a task record in my database where the due date is 2023-01-30T12:00:00.000Z. When I call my GraphQL query to fetch this task, I get 1675060200000 in localhost and 1675080000000 in my DigitialOcean server. I converted these values to human-readable format in https://www.epochconverter.com/ and got back:
Localhost:
GMT: Monday, 30 January 2023 6:30:00 AM
Your time zone: Monday, 30 January 2023 12:00:00 PM GMT+05:30
DigitalOcean Server:
GMT: Monday, 30 January 2023 12:00:00 PM
Your time zone: Monday, 30 January 2023 5:30:00 PM GMT+05:30
I expect to display Jan 30th, 2023 at 5:30 PM in my web application. Why do my local server and my DigitalOcean server return two different Unix timestamps for the same database value? I am unable to figure out if this is an issue with my database or something to do with my Apollo server configuration. What am I doing wrong? Help appreciated!
Is there is a way to scrub the x-forwarded-for field in message in logstash before sending it to logz.
Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken X-Forwarded-For
Contact the logz.io support and they can customize the message indexing for you, including dropping specific fields.
Note: I work at logz.io.
One of our Azure Logic Apps is experiencing a bizarre gap in timing from time of invocation to the time it actually begins executing. This is resulting in extremely long and erroneous run lengths. Here is an example of a problematic run:
Start date: Friday, December 13, 2019, 1:45:42 PM
End date: Friday, December 13, 2019, 2:24:30 PM
Run Duration: 38.79 minutes
Check_if_journal_file 0 Milliseconds
Condition 0 Milliseconds
Delay 1.52 Seconds
Get_Blob_Metadata 15 Milliseconds
HTTP 281 Milliseconds
ImportBreakpointJournalFile 406 Milliseconds
Initialize_JobHttpStatusCode 110 Milliseconds
Journal_file_failed_to_process 0 Milliseconds
Journal_file_successfully_processed 31 Milliseconds
Not_a_journal_file 0 Milliseconds
Set_variable 157 Milliseconds
Until 4.69 Seconds
Actual Action Execution Duration: 7.21 seconds
Action Execution Graph
Since the execution itself only took ~7 seconds, that means the logic app was just sitting there idling doing nothing for almost 38 minutes! Runs previous to this one show no timing problems.
Has anyone else seen behavior like this?
What would cause a logic app to idle for 38 minutes before beginning execution?
UPDATE:
Turned on detailed diagnostics for the logic app and got the following results which show that it really is idling or suspended. You can see that job 08586252374669322278104928528CU37 begins at 12:23 then almost immediately suspends? before taking any action and then resumes at 12:58 for no apparent reason. After resuming you can see it begins executing normally as Initialize_JobHttpStatusCode is the first action in the app.
TimeGenerated [UTC] startTime_t [UTC] waitEndTime_t [UTC] resource_runId_s resource_originRunId_s resource_actionName_s endTime_t [UTC]
12/15/2019, 12:58:57.627 AM 12/15/2019, 12:58:57.471 AM Invalid Date 08586252374669322278104928528CU37 Initialize_JobHttpStatusCode 12/15/2019, 12:58:57.549 AM
12/15/2019, 12:58:57.540 AM 12/15/2019, 12:58:57.471 AM Invalid Date 08586252374669322278104928528CU37 Initialize_JobHttpStatusCode Invalid Date
12/15/2019, 12:58:57.405 AM 12/15/2019, 12:23:38.550 AM 12/15/2019, 12:58:57.330 AM 08586252374669322278104928528CU37 08586252374669322278104928528CU37 Invalid Date
12/15/2019, 12:58:57.282 AM 12/15/2019, 12:58:56.901 AM Invalid Date 08586252353485738359883907091CU99 12/15/2019, 12:58:56.980 AM
12/15/2019, 12:58:57.258 AM 12/15/2019, 12:58:56.901 AM Invalid Date 08586252353485738359883907091CU99 Invalid Date
12/15/2019, 12:58:57.247 AM 12/15/2019, 12:58:56.909 AM Invalid Date 08586252353485738359883907091CU99 08586252353485738359883907091CU99 Invalid Date
12/15/2019, 12:23:39.275 AM 12/15/2019, 12:23:38.534 AM Invalid Date 08586252374669322278104928528CU37 12/15/2019, 12:23:39.034 AM
12/15/2019, 12:23:39.172 AM 12/15/2019, 12:23:38.534 AM Invalid Date 08586252374669322278104928528CU37 Invalid Date
12/15/2019, 12:23:39.143 AM 12/15/2019, 12:23:38.550 AM Invalid Date 08586252374669322278104928528CU37 08586252374669322278104928528CU37 Invalid Date
Logic App Suspend? Logs
Logic Apps will not be idle once its triggered. In your case, the Logic App would have retried few action for certain period. The retry policy is configurable upto 1 day. You can inspect and check the Logic App run if it has under gone some retries.
It seems there is something wrong in your "if condition". Your screenshot shows the "condition" took 0 millisecond, but it should be cancelled because of some error in the second "if condition". The run history of logic app shows 0s and misleading us.
I did a test in my side, please refer to my logic app below:
In my logic, I created a "delay" action to delay 10 minutes, then I run this logic app manually. The logic app ran the steps before the "delay" action quickly and then stayed at the "delay" action. Before 10 minutes, I use this api to cancel this logic app, we can see it was cancelled in "Run history"(shown as below screenshot).
Then I click this item in "Run history"(I clicked it after 10 minutes, if click it before 10 minutes, the condition will show x minutes and "running" status), the "condition" shows 0s(same to yours) but not 10 minutes or longer.
According to my test, the logic app run a few minutes but the "condition" just show 0s, so I think the "condition" in your logic app also took most of the time in 38 minutes, please check the two "if condition" in your logic app. I think it should be something wrong in your second condition and it result in the cancel of your first condition.
EDIT: Some users noted that this is a duplicate of ADO.NET question at
How can I get DateTime data from SQL Server ignoring time zone issues?
Please DO READ my tags, and my codes. This is nodejs question,
that has nothing to do with ADO library whatsoever. It doesn't
even run on Windows. The option noted at the link provided doesn't even exists at mssql-npm
I am creating a database for company attendance, which spans for 3 timezones.
The problem with SQL Server is that I read the working hour differently from each timezone. It registered like 1969-12-31T23:00:00.000Z, and registers as 06:00 for one timeline, and 08:00 for another. I need it to be exactly at 08:00 regardless of timezone. It means, 08:00 at western part of my country, and also 08:00 at eastern part of my country.
When I try to disable UseUTC, nodejs translated my timezone twice. For example, this is when I sent masuk field as 08:00
Sent to server:
Query sent to SQL Server:
UPDATE shift SET name = 'Shift 1', masuk = '2019-10-28T01:00:00.000Z', keluar = '2019-10-28T10:00:00.000Z', tolerance = 15 WHERE id = 1
Received the result back
And shown to the user as:
My country sits at GMT+7 to GMT+9. I don't mind if I have to flatten the timezone. But how to do that? Is there a way to read the time completely ignoring the time zone? It makes my work unnecesarily complicated.
I am using:
SQL Server 2012
Material UI
date-fns
Nodejs 12
mssql module
and this is my code to get the time from user input
<MuiPickersUtilsProvider utils={DateFnsUtils}>
<KeyboardTimePicker
key={component.field.toString()}
variant="inline"
value={value}
label={component.title}
onChange={this.eventHandler(component.field).bind(this)}
format="HH:mm"
/>
</MuiPickersUtilsProvider>
Thank you for help.
THe database uses time(7) to store the time
We are getting an error when we try to set it to a specific time every 7 days at a specific time. The doc says it is possible by using the optional [d] argument. We want to recycle every 7 days at 3 am.
http://technet.microsoft.com/en-us/library/cc754494(v=ws.10).aspx
Command :
C:\Windows\System32\inetsrv>appcmd set apppool /apppool.name: TempPool /+recycli
ng.periodicRestart.schedule.[value='7.03:00:00']
Error Message:
Application Pools
There was an error while performing this operation.
Details:
Timespan value must be between 00:00:00 and 23:59:59 seconds inclusive, with a granularity of 60 seconds
Although this question is a bit expired, but i faced it yesterday when i was writing some c# codes to manipulate an application pool programmly.
I found the sample for schedules at doc in following link which reads "adding an application pool... then set the application pool to daily recycle at 3:00 A.M.", which means we could not specify a fixed time span for recycling by add a schedule.
http://www.iis.net/configreference/system.applicationhost/applicationpools/add/recycling/periodicrestart/schedule/add#006
That's why it throws the exception to ask a time span under 23:59:59.
When you want specify a fixed time span for recycling, you should use time property from periodicRestart level.
See this doc for samples for various ways to target your requirement.
http://www.iis.net/configreference/system.applicationhost/applicationpools/add/recycling/periodicrestart#005
// add schedule to recycle at 3 am every day
appPool.Recycling.PeriodicRestart.Schedule.Clear();
appPool.Recycling.PeriodicRestart.Schedule.Add(new TimeSpan(3, 0, 0));
// set to recycle every 3 hours
appPool.Recycling.PeriodicRestart.Time = new TimeSpan(3, 0, 0);