I have created an API which creates an excel having Date columns too. When I execute the code from local it works well and displays the date as expected.
When I try executing API via Logic App, it changes the date format of that field. How can I set date time in Logic App?
When you have a fixed DateTime-Format you can use the Logic App function "formatDateTime" as follow:
formatDateTime(triggerBody()?['myDate'], 'yyyy-MM-dd')
You can find it under Expressions - Date and Time - "See more" - formatDateTime
I found some useful documentation on Microsoft's site here:
https://learn.microsoft.com/en-us/azure/kusto/query/format-datetimefunction
Here it is .. in action:
Try this to get the current date in GMT format:
The problem is your local machine is running a different Locale than the machine running your code when it is deployed.
You could either set the CultureInfo.CurrentCulture to make sure the right CultureInfo is used.
CultureInfo...
Provides information about a specific culture (called a locale for unmanaged code development). The information includes the names for the culture, the writing system, the calendar used, the sort order of strings, and formatting for dates and numbers.
You could also use the appropriate DateTimeFormatInfo, when writing the date to Excel, it
Provides culture-specific information about the format of date and time values.
Logic apps time zone base on UTC. So, it needs conversion between UTC to your local time.
In my case, 'SE Asia Standard Time', (UTC+07:00); Bangkok, Hanoi, Jakarta. So, you need to convert it as your local time. Here's in my case:
Date convertTimeZone(utcNow(), 'UTC', 'SE Asia Standard Time', 'MMMM dd, yyyy');
Time convertTimeZone(utcNow(), 'UTC', 'SE Asia Standard Time','hh:mm:ss.ff tt')
Related
I am Using Google APis .net client library to read calendar events.
I have following line of code
newRow["Start"] = pEventItem.Start.DateTime.HasValue ?
Convert.ToDateTime(pEventItem.Start.DateTime) : Convert.ToDateTime(pEventItem.Start.Date);
Where PEventItem is of type Google.Apis.Calendar.v3.Data.Event and NewRow[...] is of type DataRow. The Value of pEventItem.Start.Date is "2019-06-24" (as seen in debug window)
The above line of code works perfect, But fails when UI language / Culture is set to Arabic (SaudiArabia) The same Convert.ToDateTime throws error "String was not recognized as a valid DateTime".
btw, How i am changing the UI language is as below for your information.
Thread.CurrentThread.CurrentCulture = System.Globalization.CultureInfo.GetCultureInfo(ChangeLanguageTo);
Thread.CurrentThread.CurrentUICulture = System.Globalization.CultureInfo.GetCultureInfo(ChangeLanguageTo);
I tried to set 2nd parameter of the Convert.ToDateTime function in an hope that it will convert date correctly...
CultureInfo enUsCulture = new CultureInfo("en-us");
newRow["Start"] = pEventItem.Start.DateTime.HasValue ? Convert.ToDateTime(pEventItem.Start.DateTime, enUsCulture) : Convert.ToDateTime(pEventItem.Start.Date, enUsCulture);
Well Now it does not throw exception, but the returned date is incorrect. value retuned is {21/10/40 12:00:00 ص}
while The actual date pEventItem.Start.Date is "2019-06-24"
I also tried invariant culture also, but result is same, converted date is wrong. What could be the issue?
Regards
There are a few things going on here.
Firstly, if you use EventDateTime.DateTime (e.g. via pEventItem.Start.DateTime) you don't need to call Convert.ToDateTime, because that's already a DateTime?... you can just take the Value property to get a DateTime from a DateTime?. However, I should warn that that can perform time zone conversions that you may not want. (We can't fix the library to avoid those, as it would be a breaking change.) Instead, you may want to parse EventDateTime.DateTimeRaw, which is the original string value returned by the API.
When parsing, I'd suggest using the invariant culture using CultureInfo.InvariantCulture (instead of creating an en-US culture), and parse using DateTime.ParseExact, specifying the format you expect based on whether you're parsing a date or a full date/time.
In terms of "the returned date is incorrect" - I believe that's really just the formatted value that's using the default culture, including the calendar system. We can see that at play in the code below, which constructs the DateTime directly (so can't be affected by any text parsing etc). When formatted using the invariant culture, it shows as 2019-06-24, but when formatted with ar-SA, it shows as "1440-10-21" due to the default calendar system for that culture being System.Globalization.UmAlQuraCalendar:
// Note: when a calendar system is not specified,
// it's implicitly Gregorian.
DateTime date = new DateTime(2019, 6, 24);
Console.WriteLine(date.ToString("yyyy-MM-dd", CultureInfo.InvariantCulture));
Console.WriteLine(date.ToString("yyyy-MM-dd", new CultureInfo("ar-SA")));
So what you're seeing in the debugger is the correct date - but formatted in a way you weren't expecting.
I have a DialogFlow agent set up where one intent is used to schedule reminders. I can say something like:
"At 5pm remind me to go for a run"
And it returns the sentence to remind (in this case 'go for a run') as well as the time to set the reminder using #sys.date-time.
This works as intended, I am able to get the correct time because it just sends the time without a timezone attached.
When I use a command such as:
"In 15 minutes remind me to go for a run"
it sends the result as the time using the timezone, in this case, the incorrect one.
So right now, a result for the date-time using the API was:
2020-11-09T14:20:33+01:00
which is an hour more than it should be.
I have checked the DialogFlow agent's default time zone where it is set to:
(GMT0:00) Africa/Casablanca
Which I am fairly certain is the correct one for London time. However moving to a different timezone changes it and actually gives the correct one for the timezone (Just not my timezone)
Leaving me to wonder if this time zone is broken?
Regardless though, the Dialogflow console on the webpage returns the correct date-time but in a different format using 'startDateTime' and 'endDateTime', something that the agent does not do when sent using the API.
I have checked all configurations within the program and cannot find any evidence of any code giving a new timezone and in fact have tried to add the London timezone when a query is sent but this does not resolve the issue.
Does anyone have any advice on how to solve this?
EDIT:
After receiving a good suggestion from a user I am reminded of the most puzzling part of this issue. Chaning the timezone to GMT -1:00 vs 0:00 actually having a difference of two hours.
Around 1pm I queried it to get the time in 15 minutes.
When it was set to GMT-1:00 Atlantiv/Cape_Verde the time returned is:
2020-11-10T12:21:15-01:00
When it was set to GMT0:00 Africa/Casablanca the time returned is:
2020-11-10T14:22:07+01:00
Neither is the correct time and despite the timezone suggesting a 1 hour difference, it is actually 2 hours apart.
For London the correct timezone should be GMT -1, Casablanca Africa is GMT+1, I used this web page to determine this.
If you are in London is recommended to configure your agent to sue the correct time zone (GMT-1).
I currently convert dates from variant format to string using the VariantChangeType (or CComVariant::ChangeType). That works well, except when the time portion of the variant value is midnight. In that case, the time is simply omitted from the converted string.
A timestamp of 2015/10/07 03:40:00 is converted to a string just as you would expect: "10/7/2015 03:40:00 AM" (using my regional settings).
But a timetamp of 2015/1007 00:00:00 is converted to this string: "10/7/2015" (no time portion included).
I'm trying to preserve that midnight time, and keep the regional settings in use too. I've looked at _strftime_l() - it does include a time in the converted string, but doesn't appear to use the regional settings, even when one is provided via _get_current_locale().
I'm using C++ on Windows.
Has anyone done this?
OK - I found a way to resolve this. Windows has two API calls that will format the date and time with regional settings: GetDateFormat() and GetTimeFormat(). They each take a SYSTEMTIME structure, an output buffer, and a locale specifier. On return, the output buffer contains the date (or time) converted to a string matching the locale and regional settings in use.
I also found that _strftime_l() will actually use regional settings if you call setlocal(LC_ALL, "") first. I was a bit leery of using that method as it may have side affects I'm not aware of.
I've got a strange sybase behavior which I do not understand.
Situation
I have a table (MY_TABLE) with several columns of type smalldatetime. For illustration purposes let's assume the following table and data:
MY_TABLE||ID |TS_INIT |TS_LASTCHANGE |MY_TEXT |
||4711|3/31/2013 12:00:00 AM|3/31/2013 3:00:00 AM|someText|
TS_INIT and TS_LASTCHANGE are of type smalldatetime.
When executing the following statement I get the above result:
SELECT ID, TS_INIT, TS_LASTCHANGE MY_TEXT
FROM MY_TABLE
WHERE ID = 4711
go
My client is running in UTC+1 (Berlin) and has daylight savings time (DST) enabled.
I am not sure in what time zone the server is running and whether or not DST is enabled.
Problem
When I execute this (note that it is 03:00h):
SELECT ID, TS_INIT, TS_LASTCHANGE MY_TEXT
FROM MY_TABLE
WHERE ID = 4711 AND TS_LASTCHANGE = "2013-03-31 03:00:00:000"
go
I get NO results but when I execute this (note that it is 02:00h this time):
SELECT ID, TS_INIT, TS_LASTCHANGE MY_TEXT
FROM MY_TABLE
WHERE ID = 4711 AND TS_LASTCHANGE = "2013-03-31 02:00:00:000"
go
I do again get the above result which is saying TS_LASTCHANGE is
3/31/2013 3:00:00 AM
Note that the result prints 03:00h, even though I queried for 02:00h.
Why Is the first query returning no results even though there should be a match and why is the second query returning a result even though there should be no match?!
Note also that 3/31/2013 3:00:00 AM is the first moment in DST (at least in the year 2013) and 3/31/2013 2:00:00 AM should never ever exist at all because when transitioning from winter to summer time, the clock switches from 01:59:59 to 03:00:00 (as per this site).
Database: Adaptive Server Enterprise V15.0.3
Client: Aqua Data Studio V16.0.5
EDIT:
When querying whit the TS_INIT everything works as one would expect (only a result for 3/31/2013 12:00:00 AM)
Aqua Data Studio is written in Java.
The problem you are having has to do with the fact that Java is aware of timezones and databases don't have a concept of timezone when they store date and times. When the time comes back from the database, the database's JDBC driver puts it in a Java date and just assumes the timezone is irrelevant. The problem happens when you try to display a time which the JVM thinks is invalid, so a valid date is presented, which basically pushes the time by an hour. Daylight savings for 2015 started on March 08 2.00 AM and one of your rows contains a date which is invalid according to JVM.
This has been a known design issue with Java, and they are trying to fix this with JSR-310 for inclusion in Java SE 8. With this, they will have LocalDate, OffsetDate and ZonedDate. You can read more about it here ...
https://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api.html#jsr-310-datetime-concepts
https://jcp.org/en/jsr/detail?id=310
http://docs.google.com/View?id=dfn5297z_8d27fnf
Workaround
The only workaround, is to probably trick the JVM by setting the timezone in the JVM to GMT. If you are running ADS 16 on Windows, and you launch ADS with the shortcut icon on the desktop (which runs datastudio.exe), then you need to modify the datastudio.ini file in your folder. Add a new entry for vmarg.5=-Duser.timezone=gmt
This link explains the location of where to find the data studio.ini
https://www.aquaclusters.com/app/home/project/public/aquadatastudio/wikibook/Documentation14/page/50/Launcher-Memory-Configuration#windows
Once you have made the change, Restart ADS. Then go to Help->About->System: and double check your user.timezone setting and make sure it is GMT. Then give it a try.
With the above change there might be side effects in the application where timezone are involved, For e.g. in the Table Data Editor->Insert Current Date&Time, which would display a GMT time ... so there would be an offset.
We're getting an "unable to bind to request" when calling a service with the following querystring:
/SomeService?playerid=59326&fromdate=4-1-2014&todate=12-11-2014
We have been using this querysting format for awhile now.
The problem is some either a change in 4.0.34, or something in the OrmLightCacheClient, which we had turned off for awhile and only just recently turned it back on.
If I change the dates to following format, it seems to work.
/SomeService?playerid=59326&fromdate=2014-4-1&todate=2014-12-31.
We can roll with the changed querystring date format for now, but wanted to report the error.
When supplying a date only (i.e. doesn't include a time) it should be unambiguously defined using the YYYY-MM-DD format.