You're confused about the difference between times and representations of times. There is only a single time 1461645900000. It's the same everywhere in the universe. It's a magic moment where the stars are aligned in a certain way and the universe is at a special point in its progression.
Timezones are a function of representing a date. If I live in Tokyo, I am going to probably prefer seeing my times in Tokyo time. If I live in California, I am going to probably prefer seeing my times in California time. Such local time representations consist of a local time and an offset from UTC, so it can be properly interpreted.
When you print or output a date in JS, and it is turned into a string as it often is, of course, that string, being a representation, has to be relative to somewhere on the globe--in other words, relative to some offset. The default JS behavior is to use the offset where are you located right now, as set on your local computer. That's why you will see something like "Tue Apr 26 2016 10:15:00 GMT+0530 (India Standard Time)" if you computer is set to Indian time. You could also try date.toISOString
which would give you "2016-04-26T04:45:00.000Z" (the "Z" means UTC), or date.toUTCString
, which would ignore your local timezone and give the time relative to UTC, as in "Tue, 26 Apr 2016 04:45:00 GMT".
Just for completeness, people quite commonly confuse offsets and timezones. A timezone is a complete historical record of all offsets (which can change, such as in the case of DST) over time for a particular region. There are actually hundreds of different timezones, including one for some town in Indiana that went off DST in 1929. If you want to manage timezone data, you are going to have to handle that separately from the time itself. Even if you happen to have an offset, there is no way to go uniquely from an offset to a timezone--for instance, California and Chile are different timezones but yet are both offset -08:00. To manage timezones properly, you are going to have to use some kind of special timezone package.
I often hear people saying they "want to change the timezone". You can't change a time's timezone. Times themselves don't have timezones, they are just times on a cosmic clock. What you can do is to change the representation of a time so as to be relative to a particular offset. For example, you can use date.toLocaleString
as you have tried. What did you find to be "limited" about it?
> new Date().toLocaleString("en-US", {timeZone: "America/Los_Angeles", timeZoneName: "long"})
< "11/3/2016, 8:33:02 AM Pacific Daylight Time"
You can also use timeZoneName: "short"
, which will yield "PDT". However, "PDT" or "PST" or "IST" or anything else cannot be used as the value of the timeZone
option, because these three-letter abbreviations are not unique. For instance, "PST" could also mean "Pitcairn Standard Time".
The format you tried, giving timeZone
as a null string, will not work (yields an unidentified timezone error).
What if you want to give a string such as "IST"? As mentioned above, this will not work; you will have to find a way to map "IST" to "Asia/Kolkata", which will require some kind of library. What if you want to specify some kind of offset? Here again, you will need some kind of library which can infer a timezone from an offset.
The bottom line is that if you find yourself parsing the date, adjusting this or that component, and piecing it back together with string arithmetic, you are doing something either wrong or unnecessary.