Bug introduced in V10.4 or earlier and persisting through 12.0


Back in version 10.2 or so, Mathematica began supporting the ISO 8601 date/time format, which is nice because it's used pretty frequently. You can target the format with DateString:

(* "2017-04-28T11:45:14" *)

which was the current time when I typed that. You can import from a string using DateObject, like so:

(* DateObject[{2017, 4, 28, 11, 45, 14}, "Instant", "Gregorian", -4.] *)

The last element there is the time zone, which defaults to $SystemTimeZone, will be important later. It looks prettier in StandardForm. However, I had an externally generated string:

isoDateString = "2017-04-28T01:50:52.000Z";

If you look at the doubtless highly authoritative Wikipedia article, you'll see that the "Z" at the end there means that it should be UTC time, or in Mathematica parlance, it should have 0 for its time zone. Sadly, no!

(* DateObject[{2017, 4, 28, 1, 50, 52.}, "Instant", "Gregorian", -4.] *)

It's still using the default time zone! Is there any way to correct this that doesn't require manual string munging?

  • 3
    $\begingroup$ For the sake of an update, even 12.0+ this seems to persist. I have a bunch of data in the form "2019-11-17T00:00:00-05:00" with the 'explicit' timezone offset format, still can't be interpreted as a date. $\endgroup$ – flip Nov 20 '19 at 3:28

Just got hit by this 'issue', don't feel competent enough but it looks like something that should be reported.

So in case you know you will get UTC time (like it is in my case, this is very common setting for server responses etc) you can do:

isoDateString = "2017-04-28T01:50:52.000Z";

TimeZoneConvert @ DateObject[ isoDateString, TimeZone -> 0] (*Thanks to Karsten 7*)

enter image description here

Not very general but it is something.

  • 1
    $\begingroup$ One could also use DateObject[isoDateString, TimeZone -> 0] instead of Block[ ... ]. $\endgroup$ – Karsten 7. Jul 24 '17 at 23:56
  • $\begingroup$ @Karsten7. yep, went to far and missed the obvious way. :) $\endgroup$ – Kuba Jul 25 '17 at 6:29

You really need this as a M DateObject, right? Because if not, you could use Java 8, it has a class ZonedDateTime that guarantees the time zone with the object.







immutable, thread-safe, nano-second precision, ...



Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.