0

I currently have a var dateNow as '10 1 2016' and var timeNow as '05:15:50' and was able to convert to UTC like so var dateTimeNow = Date(dateNow + timeNow + ' UTC');

Would now like to convert it to GMT, so is it as simple as just changing ' UTC' to ' GMT'? So like, var dateTimeNow = Date(dateNow + timeNow + ' GMT');?

  • Try it... Come back if you get an error / have trouble –  Oct 03 '16 at 23:16
  • Isn't UTC = GMT+0hs? – Gabriel Oct 03 '16 at 23:18
  • Yeah, I'm in the UK and the times are the same, but I figured maybe he'd want to convert to another time zone too –  Oct 03 '16 at 23:25
  • But if he was able to get the UTC time, it's the same to get the GMT time... Maybe he needs to convert 12 to 24hs format? – Gabriel Oct 03 '16 at 23:28
  • @Tobiq Sorry but UTC is the same as GMT? And other way around? –  Oct 04 '16 at 00:33
  • @Gabriel ^^^^ Could you confirm as well? –  Oct 04 '16 at 09:06
  • UTC and GMT aren't the same, but the UTC time and the GMT time are the same, +0 offset. So.. it's the same to have either of them. Anyway, in your example you're _not_ converting it, but telling `Date` that the time you're passing to it it's UTC. I think RobG's answer is correct. – Gabriel Oct 04 '16 at 15:55
  • @Gabriel What do you mean by +0 offset? – Jo Ko Oct 04 '16 at 18:39
  • By offset I mean UTC plus/minus _x_ hours. – Gabriel Oct 04 '16 at 21:02

1 Answers1

0

If you have a date like "10 1 2016" (Which I guess is 10 January, 2016) and a time like "05:15:50" then you can create a date for that time in a timezone with a zero offset as an ISO 8601 formatted string: "2016-01-10T15:15:50Z" or "2016-01-10T15:15:50+0000".

An ISO 8601 extended format string should be parsed correctly in modern implementations, however in general it's not a good idea to parse strings with the Date constructor (or Date.parse, they are equivalent for parsing) due to variances in implementations. If you have a single format, it can be parsed in a couple of lines. Alternatively, use one of the many Date libraries that have a parser and formatter and remember to always give the parser the format of the string you wish it to parse.

As for converting a local time to UTC, you must know the time zone offset of the local time, otherwise you have no datum to adjust it.

To "convert" a local date like 10 January, 2016 at 05:15:50 to UTC (where "local" is whatever the host system time zone is set to) is a simple as:

var d = new Date(2016,0,10,5,15,50);
console.log('Local: ' + d.toLocaleString() +
            '\nUTC: ' + d.toISOString()); 

Note that toLocaleString is entirely implementation dependent, often ignores browser and system settings and produces a different result in different implementations.

This allows the host to consider the current system time zone settings and apply them when creating the date. ECMAScript Date objects have a time value that is based on UTC, so they are inherently UTC.

RobG
  • 142,382
  • 31
  • 172
  • 209
  • sorry but 10 1 2016 is actually October 1st, 2016. And is UTC supposed to be same as GMT? –  Oct 04 '16 at 01:39
  • [*UTC*](https://en.wikipedia.org/wiki/Coordinated_Universal_Time) is a time standard, [*GMT*](https://en.wikipedia.org/wiki/Greenwich_Mean_Time) is a time zone. For all practical purposes, they're the same (zero) offset, however UTC is an international standard so should be used except where GMT is expressly required. E.g. a person in GMT time zone can be expected to observe daylight saving when it applies, whereas UTC does not. There is no standard for time zone names or abbreviations (though Z is used for UTC), hence the actual offset is used for ISO 8601–compliant date and time strings. – RobG Oct 04 '16 at 01:59
  • so is UTC more widely applicable and recommended to use? –  Oct 04 '16 at 09:06
  • UTC is typically used to store dates and times as it provides a single datum and dates and times can then be converted to equivalents in any time zone depending on how the user wants it presented. Generally, everything is done in UTC and only converted to "local" for presentation. But not always, since daylight saving changes mess with durations vs recurring moments in time. – RobG Oct 04 '16 at 23:29