I want to convert Fiji(Pacific/Fiji) time to my local time.
suppose,
I have Fiji(Pacific/Fiji) time "Thu, 10 November 2016 03:47" PM and I am in India then convert it in India(Asia/Kolkata) time "Thu, 10 November 2016 08:17 AM".
so, question is
which time string need for Fiji? and how to convert it to local time in moment.js?
need to UTC string like 2016-11-16T06:30:00.000Z
working fiddel here:
http://jsfiddle.net/d06047c5/
Related
as the title says, is it possible to parse the Date from a DateBox (for example Tue Sep 17 2019 00:00:00 GMT+0200 (CEST)) to a simple date format like 2019/09/17? And also get the year value from the date alone (2019)?
Someone in the "Europe/London" (UTC +0) Timezone created a Spreadsheet. They input the date "March 22 2019" into one of the fields. This represents the date 3/22/2019 0:00 UTC+O.
I'm in the "America/Los_Angeles" (UTC -7) Timezone. When I run a Google Apps Script and try to get the value, it's evaluated as:
Thu Mar 21 17:00:00 GMT-07:00 2019
This is accurate since 3/22/2019 0:00 UTC+O == 3/21/2019 17:00 UTC-7.
The problem is when I try to get the date programmatically, I'll get it as 21 instead of 22.
For example, if I try to run:
cellRange.getValue().getDate() // returns 21 even though the sheet shows the date as 22
This is because getDate() returns values "according to local time." The local script time is UTC-7, hence it's returning 21.
However, this causes a dissonance:
Spreadsheet date: 22 (i.e. the value I see in the sheet)
Programmatic date: 21 (i.e. the one returned by getDate() above)
This is problematic when I'm trying to use a function such as joinDateAndTime_() with "March 22 2019" as the date and 6am as the time, for example. This causes it to produce a date "March 21 2019 6:00 UTC-7" instead of "March 22 2019 6:00 UTC-7".
What is the best solution here?
Not a complete solution (I'll update soon)
It seems like this is what is happening:
The value is hard-coded as "March 22" (text).
When a user opens the sheet, no matter what timezone they are in, it'll assume it represents March 22 in the sheet's timezone. 3/22/2019 0:00 UTC+0
Once you read the value into a JavaScript Date, all date functions assume you want it in your current (aka the script's) timezone. 3/21/2019 17:00 UTC-7
Solution A: Just add the hours
Forget about the timezones. Instead of hardcoding the hours in a Date, just offset the date by the hours you want.
The only downside is you need to be certain that the date started at 0:00 according to whatever timezone it was in. (E.g. if they decided to write "March 22 2019 5:00", then you'll be offsetting the hours incorrectly.)
Solution B: Do some math
I'll update this soon, but eventually you might want a function sheetTimezoneOffset() that could be used like this:
function getDate(cellRange) {
var date = cellRange.getValue().getDate();
var extraneousHours = formatDate(date, "h", sheetTimezoneOffset());
date = date.addHours(-extraneousHours);
var offsetHours = 6; // e.g. for 6am
date.addHours(offsetHours);
return date;
}
I need help with this scenario:
1) Currently it is summer time. I need to create a time interval for June 9 Monday 6 PM - 7 PM EDT and every week after that until end of 2018. This interval will be for students to schedule appointments with a tutor. The client right now sends that as a request for creating start time at June 9 Mondays 2 PM UTC. (EDT is -4 hours offset) The server creates a start time in db for June 9 2 PM UTC and adds 7 days worth of milliseconds to create recurring
^ this causes an issue because of DST. Let's say it is right now November 5th (which is after daylights saving change). The DB still has Nov 5, 2 PM UTC saved as value. But because my timezone changed, instead of offsetting by 4 hours like I did on June, I offset by 5 hours. So the correct start time is "6 PM session in my timezone" becomes "7 PM my timezone". this is the error
the solution is either of one of two (or combination of both):
1) instead of adding 7 days worth of milisecond, you add 1 week worth of miliseconds depending on the user's timezone Currently, there's no way to extract a person's timezone based on utc offset (-400, which is right now in east coast USA, is also applicable to Canada, Carribeans, South America etc. We need to save a user's timezone as a string, rather than UTC offset count. There is an international standard for timezones)
2) ?? something else
I have a few UNIX timestamps that I've been converting back and forth, and I notice that the last number of the timestamp would change without causing any difference in the date.
For example, if you convert this number to normal date:
1452120848 > 6-1-16 17:54
But if you convert it back:
6-1-16 17:54 > 1452120840
As you can see the last number was changed to a zero. I tried some of the online converters and discovered that the last number could be any number and the date wouldn't change. What does it mean?
The unix time is the time in seconds since 1970.
You don't convert the seconds part of your date, thus it's 'lost' - your numbers may differ by up to 60.
The timestamp of 1452120848 is actually: Wed Jan 6 22:54:08 2016
So you're missing 8 seconds.
The UNIX timestamp gives you the seconds since 1st January 1970 00.00.00 UTC. Since this is seconds and you are just printing up to minutes, the difference is not shown.
However, they are not the same date:
$ date -d#1452120848
Wed Jan 6 23:54:08 CET 2016
$ date -d#1452120840
Wed Jan 6 23:54:00 CET 2016
In ext-js ,
I have a data in millseconds ..eg;850248000000 for DOB field.
it is what i get from server side.
I need to convert this to Date format to be shown in a browser.
Time Zone at the Client Side should not affect the conversion.
Appreciate your help.
kp
The first thing to know would be what the time means(thanks #Teo). If it's epoch time in ms, the following might work for you
var d = new Date(850248000000)
console.log(d.toGMTString())
>>>Tue, 10 Dec 1996 20:00:00 GMT VM309:2
console.log(d.toLocaleString())
>>>12/10/1996 3:00:00 PM VM310:2