Thanks for the tip! I would at least want to test it on FF and IE and on various OS platforms though. The reason for going to all the trouble of using the setUTCMonth() etc methods instead of just letting the Date() constructor parse the string was that the behaviour was inconsistent, possibly platform dependent. AFAIK the date string formats it can parse are undocumented. From my reading of ISO 8601 a string ending in ‘UTC’ is not valid so it’s odd if that was parsed correctly, possibly the ‘UTC’ is not even understood but an unrecognised timezone just defaults to UTC+0 or something so it works by lucky chance. But it’s a good point about the code above only working in GMT. I guess therefore we should strip off the ‘Z’ as before and then manually add the current local timezone offset to the following line: _date.setUTCHours(Number(timeHours) + [your timezone offset]).

‘UTC’ is not valid in iso8601, but it is valid in whatever parsing format string JS is using. Chrome’s date parser (new Date(s)) parses iso8601 strings, including “T” and “Z”, correctly, but Safari’s (and I presume others) are expecting a different format, one with slashes instead of dashes, a space between the time and date parts, and a time zone indicator like “UTC”. Sadly, it *doesn’t* seem to correctly parse “+00:00” in place of “Z”, but I didn’t exhaustively test all the permutations once I got it working. Koding Php Stok Tidak Tersedia more.

ISO-8601 (example: 2005-08-15T15:) Note: This format is not compatible with ISO-8601, but is left this way for backward compatibility reasons. Use DateTime::ATOM or DATE_ATOM for compatibility with ISO-8601 instead.

I dunno about your timezone offset code. Canon Lbp 1210 Driver For Windows 7 64 Bit. All I can say is, be very careful with time zones! It’s very easy to change the hours when you should have changed the zone, or vice versa, or both, or neither The JS date does correctly convert UTC times in local time when asked, e.g. Via date.toTimeString(). Someday, someone will write the perfect Date/Time/DateTime/TimeZone/Locale library and port it to all major lanugages. And then nobody will use it.

I've written a simple method to parse a specific kind of (GMT, with milliseconds), into a DateTime. I'm looking to replace it with something that can parse any ISO 8601 timestamp (with or without element separators, missing elements like seconds or milliseconds, with timezone, etc.) Rather that re-inventing the wheel, I'm wondering about using a built-in method. A similar pointed out that, 'JAXB must be able to parse ISO8601 date string according to the XML Schema specification'. I don't know what JAXB is, or whether it's available from Apex, but I do know that Apex has all sorts of XML parsers and WSDL tools. The XMLNode class doesn't have an ISO 8601 parser, but I did find mention of one as part of the ( getDatetimeValue() method), and I plan to use that in a wrapper for my conversion. I'm wondering: • If there's something simpler.

• If there are known limitations of getDatetimeValue() from JSONParser. Rich's answer was promising, so I tried to figure out why it wouldn't work, so did a bit of debugging and found that something like this: System.debug(json.deserialize(json.serialize(datetime. Hp Ipaq Install Windows Mobile. now()), datetime.class)); would print the current datetime, and that System.debug(json.serialize(datetime.now()); does in fact serialize to ISo 8601 format, so after a couple of minutes of staring, I realized that the string has to be a valid JSON string, which means, we need double-quotes around it.