I am implementing integration with external service which requires current date and time. The documentation of the service says that it accepts the datetime in ISO 8601 format, but that's only partially true – it doesn't support timezone offset.
When I try ${date:now:yyyy-MM-dd'T'HH:mm:ssZ} in Camel, I get 2017-08-16T21:45:10+0200, which is not acceptable by the service.
Is there a way to make Camel date format output current date in UTC? I would like to get 2017-08-16T19:45:10Z instead of 2017-08-16T21:45:10+0200.
I would like to avoid writing separate bean for that, so I prefer solution implemented purely in XML DSL.
I've managed to come up with a solution using Groovy expression:
<groovy>
java.time.ZonedDateTime.now(java.time.ZoneOffset.UTC)
.format(java.time.format.DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ssX"))
</groovy>
Camel Simple language has date-with-timezone variable that can be used to query time of different time zones like:
${date-with-timezone:now:CET:yyyy-MM-dd'T'HH:mm:ss}
${date-with-timezone:now:UTC:yyyy-MM-dd'T'HH:mm:ss}
${date-with-timezone:now:EST:yyyy-MM-dd'T'HH:mm:ss}
That would become:
2022-03-22T16:08:43 // CET is UTC+1
2022-03-22T15:08:43 // UTC
2022-03-22T10:08:43 // EST is UTC-5
The last parameter is java.text.SimpleDateFormat pattern that you can use to get whatever time zone designator you would like to have. E.g.
${date-with-timezone:now:UTC:yyyy-MM-dd'T'HH:mm:ssX}
Gives you:
2022-03-22T15:08:43Z
Related
I'm pretty new to Logic App so still learning my way around custom expressions. One thing I cannot seem to figure out is how to convert a FileTime value to a DateTime value.
FileTime value example: 133197984000000000
I don't have a desired output format as long as Logic App can understand that this is a DateTime value and can be able to run before/after date logic.
To achieve your requirement, I have converted the Windows file Time to Unix File Time then converted to File time by add them as seconds to a default date 1970-01-01T00:00:00Z. Here is the Official documentation that I followed. Below is the expression that worked for me.
addSeconds('1970-01-01T00:00:00Z', div(sub(133197984000000000,116444736000000000),10000000))
Results:
This isn't likely to float your boat but the Advanced Data Operations connector can do it for you.
The unfortunate piece of the puzzle is that (at this stage) it doesn't just work as is but be rest assured that this functionality is coming.
Meaning, you need to do some trickery if you want to use it to do what you want.
By this I mean, if you use the Xml to Json operation, you can use the built in functions that come with the conversion to do it for you.
This is an example of what I mean ...
You can see that I have constructed some XML that is then passed into the Data parameter. That XML contains your Windows file time value.
I have then setup the Map Object to then take that value and use the built in ado function FromWindowsFileTime to convert it to a date time value.
The Primary Loop at Element is the XPath query that will make the selection to return the relevant values to loop over.
The result is this ...
Disclaimer: I should point out, this is due to drop in preview sometime in the middle of Jan 2023.
They have another operation in development that will allow you to do this a lot easier but for now, this is your easier and cheapest option.
This kind of thing is also available in the Transform and Expert operations but that's the next tier level of pricing.
I am creating a native query for Hibernate using the following code
final Query countQuery = entityManager.createNativeQuery( countSql );
if ( countCriteria.getStartDate() != null ) {
final String startDate = countCriteria.getStartDate().toString();
countQuery.setParameter( START_DATE_PARAMETER, startDate );
}
Where startDate on my class is an org.joda.time.DateTime and toString() returns "2019-05-13".
These query parameters work fine in production, which is running against MS Sql Server. (ick!)
Now, the unit test is running against HSQLDB. I'm providing the same values and it throws:
javax.persistence.PersistenceException: org.hibernate.exception.DataException: data exception: invalid datetime format
When it attempts to run the query.
Since the parameter is formatted exactly the same, I'm assuming that the problem is the format of the date string for HSQLDB.
So, now what? How do I move forward with this? I've checked the setParameter format that takes TEMPORAL or whatever, but that won't work for JODA time.
I've already talked to my tech lead about not using native queries, but using hibernate queries, but it has fallen on deaf ears. Do I have another option so I don't have to battle my tech lead to write unit tests for our DAOs?
Well, I'm embarrassed to admit how long it took me to figure this one out.
I simply converted the LocalDate to a java date, then used that to set a TemporalType parameter.
Date date = localDate.toDate();
countQuery.setParameter(parmName, date, TemporalType.DATE);
This seems to be working fine.
I'm trying to format the current date according to the generic "2012-09-04 10:20:12 AM" format but somehow the the "AM" part is always missing.
I'm using the expression "..." & Format(CDate(Now), "yyyy-MM-dd hh:mm:ss tt") to format the date and append it to some text. That emits the warning reproduced below but prints out the date correctly (except for the AM/PM designator).
[rsRuntimeErrorInExpression] The Value expression for the textrun
‘EmissionDate.Paragraphs[0].TextRuns[0]’ contains an error: Input string
was not in a correct format.
What am I doing wrong here?
Note: I'm aware of this SO post and SQL Server query backed solutions but I'd like to use the built-in functions as much as possible.
I found this article and maybe it can solve your problem. I know you are already using Format(CDate) but since you are using (Now), witch is a datetime variable, maybe you should use FormatDateTime() instead of Format().
Try this as well:
Instead of: Format(CDate(Now), "yyyy-MM-dd hh:mm:ss tt")
Use: Format(CDate(Now), "yyyy-MM-dd hh:mm:ss am/pm")
Link:Working with Dates in Reporting Services
As per my previous comment, the report's Language property was referencing a culture for which no AM/PM designator was defined. Changing it to en-US presented the AM/PM designator as expected.
I have a problem.
I have an application in C# with SQL SERVER 2005 as backend.
The problem is in fetching the correct record based on the date.
The frontend code is
if (string.IsNullOrEmpty(txtFromDate.Text))
SelectCmd.Parameters[0].Value = DBNull.Value;
else
SelectCmd.Parameters[0].Value = txtFromDate.Text;
Now if I run usp_NewGetUserDetail '03/04/2010' in the query analyser, I am able to get the correct record.
So I am preety confident that my SP is correct(I have tested with many variations).
But if the same value is passed from front end code(SelectCmd.Parameters[0].Value = "03/04/2010";), I am getting some unexpected record. By that I mean , the records which are not in the date range.
I guess that there is some mismatch in date format of backend and frontend.
Kindly let me know if I missed out some information that I need to provide for solving this
Please help.
Dealing with dates on SQL Server is a tricky business, since most formats are language- and locale-dependent. As Adam already mention - you should try to avoid dealing with dates as strings - it does get messy, and using DateTime (both in .NET and in T-SQL) is much safer and easier.
But if you must use strings, then be aware of these points: a date like 02/05/2010 will be interpreted as Feb 5, 2010 in some places, or as May 2, 2010 in others. So whatever you're doing - you'll always run into someone who has a different setting and gets different results.
The way to do here is to use the ISO-8601 format which is independent of all locale and language settings and just always works.
So for your dates, always use the YYYYMMDD format - first of all, it always works, and second of all, with that format, you get a "natural" sort behavior - sorted by Year, then Month, then Day.
There's no need to pass the date as a string, nor should you. Set the value of the parameters to a DateTime object that represents the date you want, not the string representation of it.
Try something like this:
DateTime fromDate;
if (DateTime.TryParse(txtFromDate.Text, out fromDate))
{
SelectCmd.Parameters[0].Value = fromDate
}
else
{
SelectCmd.Parameters[0].Value = DBNull.Value;
}
When supplying dates to a stored procedure via a parameter I'm a little confused over which format to use for the dates. My original VBA syntax used the ADO Connection object to execute the stored procedure:
Set SentDetailRS = Me.ADOConnectionToIntegrity.Execute("dbo.s_SelectAggregatedSentDetailList '" & fCSQLDate(EffectiveDate) & "'", , adCmdText)
This works fine for me using the date syntax yyyy-mm-dd but when another user executes the code they recieve the error: 13 'Type Mismatch'.
After some experimentation I found that supplying the date in the format dd/mm/yyyy fixes this error for the user but now gives me the error!
Executing the stored procedure using a command object with parameters works regardless of the format of the date (I assume ADO is taking care of the formatting behind the scenes). I thought that using the format yyyy-mm-dd would work universally with SQL Server?
I'm also perplexed as to why this problem appears to be user specific? I noticed that my default language on SQL Server is 'English' whereas the other user's default language is 'British English', could that cause the problem?
I'm using ADO 2.8 with Access 2003 and SQL Server 2000, SQL Server login is via Windows integrated security.
Be careful, and do not believe that ADO is taking care of the problem. Universal SQL date format is 'YYYYMMDD', while both SQL and ACCESS are influenced by the regional settings of the machine in the way they display dates and convert them in character strings.
Do not forget that Date separator is # in Access, while it is ' in SQL
My best advice will be to systematically convert your Access #MM-DD-YYYY# (or similar) into 'YYYYMMDD' before sending the instruction to your server. You could build a small function such as:
Public function SQLdateFormat(x_date) as string
SQLDateFormat = _
trim(str(datePart("yyyy",x_date))) & _
right(str(datePart("m",date)),2) & _
right(str(datePart("d",date)),2)
''be carefull, you might get something like '2008 9 3'
SQLDateFormat = replace(functionSQLDateFormat," ","0")
'' you will have the expected '20080903'
End function
If you do not programmatically build your INSERT/UPDATE string before sending it to the server, I will then advise you to turn the regional settings of all the machines to the regional settings of the machine hosting SQL. You might also have to check if there is a specific date format on your SQL server (I am not sure). Personnaly, I solved this kind of localisation problems (it also happens when coma is used as a decimal separator in French) or SQL specific characters problems (when quotes or double quotes are in a string) by retreating the SQL instructions before sending them to the server.
I would guess that fCSQLDate function is culture-specific - i.e. it will parse the date based on the user's locale settings. That's why you see the problem.
Anyway, using queries with concatenated strings is always a bad idea (injection attacks). You are better off if you use parameters.
Access uses # as date field delimiter. The format should be #mm/dd/yyyy# probably the #mm-dd-yyyy# will also work fine.
Sorry I don't know mysql, but with oracle I would always explicity state the format that I was expecting the format to be in, eg: 'DD-MM-YYYY', to avoid (regional) date format problems
Why not use the format
dd mmm yyyy
There is only one way it can be interpreted.
You can use the Date() function to return a universal date based on the machine date and time settings. The region settings on the machine will determine how it it formatted on the client end. If you leave the field as strictle a DateTime field then the cleint region settings can format the date.
Going into the server, using the Date() function should aslo work (returning a universal date value).
Also, use a command object and parameters in your query when you pass them to avoid SQL injection attacks on string fields.