new Date().toLocaleString not working on chrome - date

I want to display UTC date '2020-01-14T17:43:37.000Z' in local timezone.
I am getting output like this :-
new Date('2020-01-14T17:43:37.000Z').toLocaleString(undefined, {dateStyle: "medium", timeStyle: 'long'});
Chrome
'Jan 14, 2020, 11:13:37 PM GMT+5:30'
FireFox
14-Jan-2020, 11:13:37 pm IST
How can i display Date in local timezone consistently accross all browsers?

Consistency is not guaranteed with toLocalString. All that's guaranteed is that the output is in a format that is reasonable to display to the user given the options specified.
That said, you can get the result you're looking for if you specify en-IN for the locale code, and Asia/Kolkata for the time zone.
const result = new Date('2020-01-14T17:43:37.000Z')
.toLocaleString('en-IN', {
dateStyle: "medium",
timeStyle: 'long',
timeZone: 'Asia/Kolkata'
});
console.log(result);
You probably don't want to hardcode those into your application though. In your original code, undefined means to use the user's default locale, and the absence of timeZone means to use the user's default time zone. If the user happens to have en-IN and Asia/Kolkata, then they will see the same result as above.

Related

Google Calendar api ignores timezone

Im using the CalendarApi in flutter and in order to get events I use the list method like that:
calendarApi.events.list(
cls.calendarId,
timeZone: <specific timezone>
timeMin: DateTime.now().today().toUtc(),
timeMax: DateTime.now().tomorrow().toUtc(),
),
No matter what timezone I tried it always return the event start and end date in UTC format.
I tried using the timezones in multiple formats:
America/Los_Angeles
UTC - 08:00
GMT format
Pacific Standard Time
None of the following worked.
In addition in the in google calendar's settings the timezone is set correctly.
From the documentation:
Must be an RFC3339 timestamp with mandatory time zone offset, for example, 2011-06-03T10:00:00-07:00, 2011-06-03T10:00:00Z. Milliseconds may be provided but are ignored. If timeMax is set, timeMin must be smaller than timeMax.
Make sure the strings you are sending follow one of these pattens:
YYYY-MM-DDTHH:MM:SS±HH:MM
or
YYYY-MM-DDTHH:MM:SSZ
So for example, the time that this answer was posted would be:
2021-07-27T16:08:02+02:00
or:
2021-07-27T14:08:02Z
Where the Z signifies 'Zulu', or UTC.

Compare String time to Local Server Time

Have a string object with a specific format of date.
Need to check if that dateStr is after the current time on local machine.
Having trouble with conversions and LocalDateTime
String dateStr = "Oct 27 2017 02:29:00 GMT+0000";
public static final String DATE_FORMAT = "MMM dd yyyy HH:mm:ss zzzZ";
I know something is fishy in the below code with the usage of LocalDateTime
public static boolean isFutureDate(String dateStr){
DateTimeFormatter formatter = DateTimeFormatter.ofPattern(DATE_FORMAT);
LocalDateTime dateTime = LocalDateTime.parse(dateStr, formatter);
return(dateTime.isAfter(LocalDateTime.now()));
}
Trouble is with timezones and date conversions.
Please help find the right way of checking if a dateStr is after the current local date this in Java 8?
Local… types have no time zone
You are using the wrong type for your data.
The Local… types including LocalDateTime purposely have no concept of time zone or offset-from UTC. As such they not represent a moment on the time line, only rough idea of a range of possible moments. Use LocalDateTime only when the time zone is unknown or irrelevant; never use it for an actual moment in history.
Use OffsetDateDate for values with an offset-from-UTC, a number of hours and minutes.
Use ZonedDateTime for values with an assigned time zone. A time zone such as Asia/Kolkata or America/Montreal is a particular region’s history of past, present, and future changes to its offset-from-UTC. Anomalies such as Daylight Saving Time (DST) mean a change to the offset.
If you know all your inputs are in GMT/UTC, use OffsetDateTime. If the inputs may use time zones, parse as ZonedDateTime objects.
This input data format is terrible. If you have any control, use standard ISO 8601 formats instead when exchanging date-time values as text.
All this has been covered many times already on Stack Exchange. Please search more thoroughly before posting. And search Stack Overflow to learn more. I kept my Answer here brief, as this is a duplicate.
When parsing to a LocalDateTime, you're ignoring the offset (+0000), and I'm not sure if that's what you really want.
In this case, the +0000 offset means the date/time is October 27th 2017 at 02:29 AM in UTC. When you parse to a LocalDateTime, you're ignoring the offset (so it represents only "October 27th 2017 at 02:29 AM", not attached to any timezone) and comparing to your local date/time (or the current date/time in the JVM's default timezone).
If you want to make a comparison that also considers the offset, you can parse it to OffsetDateTime and convert to Instant to compare it with the actual UTC instant, regardless of the timezone.
Also, the month name is in English (I'm assuming it's English, but you can change this accordingly), so you must a java.util.Locale in the formatter (if you don't set a locale, it'll use the JVM default, and it's not guaranteed to always be English):
// parse to OffsetDateTime (use the same formatter)
String dateStr = "Oct 27 2017 02:29:00 GMT+0000";
DateTimeFormatter fmt = DateTimeFormatter.ofPattern("MMM dd yyyy HH:mm:ss zzzZ", Locale.US);
OffsetDateTime odt = OffsetDateTime.parse(dateStr, fmt);
// compare Instant's
System.out.println(odt.toInstant().isAfter(Instant.now()));
Although it works for you now, keep in mind that the default locale can be changed without notice, even at runtime. If your input has locale-sensitive date (such as month names), it's better to specify it as above.

Moment JS setting TimeZone to EST - alloy/moment

I am using momentjs in alloy framework in Appcelerator. My api returns the date as - 2017-09-06T12:03:00.000Z I am using below code to format this date into readable form -
var dt = moment(record.createddate);
$.dateValue.text = moment(dt).format('lll');
But the output I get is - Sep 6, 2017 5:33 PM, which is not correct as the date saved in db and returned from api is EST and the date getting displayed is GMT+0530. How should i format this date so that I get the correct date value?
I guess, somewhere in your code, the moment's default timezone is set to GMT+0530. Something like moment.tz.setDefault('Asia/Colombo') could do this.
You can define in what timezone you want to display your date. This should work for you :
moment('2017-09-06T12:03:00.000Z').tz("Etc/GMT").format('lll')
Or if you want the value I suggested in the comments :
moment('2017-09-06T12:03:00.000Z').tz("Etc/GMT-2").format('lll')
For more informations about moment.js timezones, you can check the moment.js timezone docs.
Hope this helps !

How to convert a ISO8601 date time string to a simple date time format in XSL version 1.0?

I have a ISO8601 string (e.g. date="2015-07-10T04:31:25") I need to convert this to the format:
July 7, 2015, 4:31:25 PM (EDT)
Even though I can write a template and use substring() to transform the string in the date time format. However I am not sure how to achieve the AM/PM and time zone information?
Working code templates would be highly appreciated. Thanks!
I am not sure how to achieve the AM/PM ...
It can be calculated from the hour component as:
substring('AMPM', 1 + 2*(number($hour) > 11), 2)
Of course, in the given input, where $hour would be "04", the correct result is "AM", not "PM".
... and time zone information?
Your input does not contain any time zone information, so unless you want to hard-code EDT as a string, there is no way to get it.

How can I shift timezone of Date object created in local timezone to target timezone in GWT client?

How can I shift timezone of Date object created in local timezone to target timezone?
Here is what I need. I want web-client to pick a date using DatePicker but resulting Date object should look like as if it was picked in another timezone. Since there is no way to tell DatePicker to do that I have to manually shift date.
For example it's Apr 6th 2012 2:42AM in California right now. Created Date will be in UTC-7 timezone. I want to have Date object with Apr 6th 2012 2:42AM in Europe/Moscow timezone.
Here is I do it right now:
final TimeZoneConstants constTz = GWT.create(TimeZoneConstants.class);
final TimeZone timeZoneMsk = TimeZone.createTimeZone(constTz.europeMoscow());
final TimeZone timeZoneCali = TimeZone.createTimeZone(constTz.americaLosAngeles());
Date curTime = new Date();
DateTimeFormat dateTimeFormat = DateTimeFormat.getFullDateTimeFormat();
Date mskTime = new Date(curTime.getTime() - (curTime.getTimezoneOffset() - timeZoneMsk.getStandardOffset()) * 60 * 1000);
String strLocal = dateTimeFormat.format(curTime, timeZoneCali); // Friday, 2012 April 06 02:42:59 Pacific Daylight Time
String strMsk = dateTimeFormat.format(mskTime, timeZoneMsk); // Friday, 2012 April 06 02:42:59 Moscow Standard Time
There are two problems with this method:
If you ask me it looks pretty bizarre.
Timezone in mskTime is still -0007. I wonder if it can cause any problems in future when I deserialize this object from Google App Engine datastore.
Or should I just produce string with full date of local Californian time, replace timezone in string and then generate new Date by calling DateTimeFormat.parse() ? It looks pretty hacky too...
Also what do you think of JodaTime for GWT ? Is it stable enough for production ?
Your code looks about right. Using DateTimeFormat.parse might make the intention clearer to a casual reader. It's not very often that you are given timezones A and B and one Date object, and you have to produce a new Date object that, when formatted in B, has the same time as the original when formatted in A.
Timezone in mskTime is still -0007. I wonder if it can cause any problems in future when I deserialize this object from Google App Engine datastore.
No, there can be no problems. Remember that a Date object represents a universal point in time not bound to a timezone. When it's April 6 14:40 in Moscow, it's April 6 03:40 in California, so the Date objects are equal.