I am trying to post date value to backend. But the value is sometimes increment/decrement by 1 in sap gateway. I have tried many possible solutions. But no luck. I am working between two time zones EST and IST. How to reoslve this?
var syFormat = sap.ui.core.format.DateFormat.getDateInstance({
pattern: "yyyy-MM-ddTHH:mm:ss",
UTC : true
});
var f = syFormat.format(d);
Is there some purpose behind setting UTC to be true? Because due to this, the time is being formatted and parsed according to UTC instead of your local timezone.
You can try to perform the formatting without setting the 'UTC' parameter.
Related
The DateTime created by DateTime.parse seems to always returns 0 for "timeZoneOffset"
I create a ISO8601 string here in a non UTC timezone: https://timestampgenerator.com/1610010318/+09:00
I pass that string to DateTime.parse:
DateTime date = DateTime.parse("2021-01-07T18:05:18+0900");
Issue: timeZoneOffset is 0 when I was expecting +0900.
print(date.timeZoneOffset); --> 0:00:00.000000
print(date.timeZoneName); --> UTC
print(date); --> 2021-01-07 09:05:18.000Z
Dart DateTime documentation (https://api.dart.dev/stable/2.10.4/dart-core/DateTime/parse.html):
The result is always in either local time or UTC. If a time zone offset other than UTC is specified, the time is converted to the equivalent UTC time.
Why is timeZoneOffset 0? What string do I need to pass to DateTime.parse to get it to store the time in local time instead of converting it to the equivalent UTC time?
The Dart SDK does not really handle different timezones which is the reason why the parse want local timezone (which is the timezone on the system running the program) or UTC.
If you are trying to parse a timestamp without any timezone information, Dart will assume the time are in local timezone (I am in Denmark which are using the Romance Standard Timezone):
void main() {
print(DateTime.parse("2021-01-07T18:05:18").timeZoneName); // Romance Standard Time
print(DateTime.parse("2021-01-07T18:05:18+0900").timeZoneName); // UTC
}
You can convert your UTC timestamp into localtime by using .toLocal() on the timestamp. But again, this will just convert it into the timezone which are on your own system and not the one coming from the time you have parsed:
void main() {
print(DateTime.parse("2021-01-07T18:05:18+0900").toLocal().timeZoneName); // Romance Standard Time
}
If you want to handle time with timezone data you should look into the package timezone: https://pub.dev/packages/timezone
Some notes about saving timezone offset
You should be aware that in most cases, it does not really makes sense to save the time in a form where you can get the original offset again. The problem is that most countries have rules like DST or the user are traveling and does expect the system to handle the time correctly.
So in a lot of cases, the user does not really expect to get the same offset back again but want the time to be with the currently offset based on location and time right now.
The timezone package does e.g. not allow you to parse a timestamp and save the offset together with it (because an offset is not the same as a location). Instead, it want you to specify the location the timestamp are used for so it can calculate the current offset for that location.
So in general, I recommend you to always save time as UTC on storage. When the data are going to be used, you should have some way to know the location of the receiver (e.g. ask the user in some form of profile) and convert the time to that location using the timezone package. If the application are running on a device owned by the receiver of the data, you can convert the UTC to local time using .toLocale().
I recently started using Grafana to show data I have in my PostgreSQL Database.
Now I've reached a point where when selecting data and using a certain timestamp field as the "time" field in Grafana, the data that's shown is the dates + timezone difference.
For example:
My data has the timestamp "2020-08-24 12:05:30" and my timezone is UTC+3, but Grafana shows it as "2020-08-24 15:05:30".
Is there any way to simply display the data as it exists in my DB without adding that timezone difference?
Go to the dashboard settings and make sure the timezone is set to UTC or whatever timezone is used by the data.
Changing the timezone wasn't my solution, as it would also shift "now".
I simply added an interval to my query:
TO_TIMESTAMP(DateTime, 'YY-MM-DD HH24-MI-SS') - interval '2 hour' as time
to shift it 2 hours
The way I think it is intended to be used is:
Storing of dateTime values in the database should be in UTC only. (E.g. send a string representation of datetime.datetime.utcnow() to PostreSQL).
If you then select your timezone in Grafana's settings, things should work as expected.
I'm developing a Clio integration with access to the calendar, but there's been an issue with dates. While the documentation says they expect an ISO-8601 timestamp date, it seems like there's something adding offset to the timezone value in dates being sent to the system.
For example, if I send a date 2018-05-17T23:59:59.999999-04:00 on both start_at and end_at properties when creating a calendar entry for an all day event, the value returned when fetching this entry through the API is 2018-05-17T17:00:00-07:00, which is clearly wrong. Am I missing something here?
The expected result should be something like either 2018-05-17T23:59:59-04:00 or 2018-05-18T03:59:59Z if milliseconds are ignored.
All dates are based on UTC timezone. Could it be that your site/server/script is set to a local timezone and so the dates are off for part of the day?
Try setting your scripting environment to UTC time before making any date/time-based queries.
I have an issue where I'm providing a to date, then filtering some odata on that date....
var effectiveTo = moment(oArgs.effectiveDateTo).format('YYYY/MM/DD 00:00:00');
new Filter("StartDate", FilterOperator.LE, moment(new Date(effectiveTo)).toDate())/
The problem is, if the date falls after the 26th March, +1 is added to the time in the StartDate, so the filter no longer returns the correct data.
Any ideas how I get around this?
The problem is that when exchanging data with OData service values of DatTime type automatically converted to and from local browser timezone and also light saving periods. Probably you should pass Dates as strings? I've seen such a technique in standard SAP Fiori applications.
this is how SAP Leave Request app prepares dates before sending to the backend:
sStartDate = hcm.myleaverequest.utils.Formatters.DATE_YYYYMMdd(_oStartEndDates.startDate) + 'T00:00:00';
sEndDate = hcm.myleaverequest.utils.Formatters.DATE_YYYYMMdd(_oStartEndDates.endDate) + 'T00:00:00';
I send timestamps to my GWT client using GMT/Zulu time, with each string designated as such (ie. 2012-01-19T16:29:18Z, or 4:29pm GMT). How do I show this in the browser in the local timezone? So for me in CST I expect to see 10:29am.
If I do no formatting I get the date as 4:29pm, which I expect, If I use a TimeZone object of TimeZone.createTimeZone(0), I get for some reason 10:29PM (not AM as expected). I suppose I'm supposed to pass in something more meaningful than 0, but how do I obtain the right value for the where the browser is running?
J
You can get the time-zone offset that is configured in the browser using:
Date d = new Date();
d.getTimezoneOffset();
It won't give you the timezone name, I don't think that's possible to get.
Do you send the time as a timestamp, or string? I find the best approach is to send UTC timestamps to the client and then format them to whatever zone I need using DateTimeFormat/TimeZone. But I guess that if you are parsing the date string including the offset, you end up with a UTC timestamp anyway.
If you want the GWT client code to format the time in the browser time zone, you should pass the data from the server to the client as a java.util.Date object.