# Is DateString supposed to be truncating seconds?

If I configure DateString to format dates as ISO dates with

$DateStringFormat := {"Year", "-", "Month", "-", "Day", "T", ":", "Hour", ":", "Minute", ":", "SecondExact", If[$TimeZone == 0, "Z", "UTC" <> ToString[$TimeZone]]}  I get truncated seconds, rather than rounded seconds {2012, 10, 12, 21, 32, 22.5359} // DateString 2012-10-12T:21:32:22.535UTC-5.  This seems wrong. The result should either be 2012-10-12T:21:32:22.5359UTC-5.  or 2012-10-12T:21:32:22.536UTC-5.  Is it a bug, or am I misunderstanding "SecondExact" or DateString? - Looks like it only supports a maximum of three decimal places in "Millisecond". – Eli Lansey Dec 4 '12 at 20:34 What the OP is complaining about is caused by simple mistake. DateString only handles time to down to the millisecond level. Therefore, putting 22.5359 into the seconds slot of a date list, which is asking for time at the 100 microsecond level, is just not going to work. Not surprising that DateString truncates it. – m_goldberg Jan 8 '14 at 5:07 I believe this is documented: With a typical value for$DateStringFormat, DateString[{y, m, d, h, m, s}] will truncate fractional seconds. –  Sjoerd C. de Vries Jan 8 '14 at 6:37
@SjoerdC.deVries but, OP is explicitly specifying "SecondExact" as part of the format, which supposedly represents "seconds including fractions". m_goldberg is right that DateString truncates these values, but it isn't really documented as such, there seems to be no good reason for it, and it certainly isn't OP's mistake. I would call it a bug. –  Oleksandr R. Jan 8 '14 at 13:51
@OleksandrR.: Yes, that's my question. The documentation is hardly clear. The way I read it, it was describing the purpose of "SecondExact", by showing what happened if one used a "typical" format instead. If instead of "a typical value" they mean "all values", they should say so (and explain that "SecondExact" doesn't really do anything). –  raxacoricofallapatorius Jan 8 '14 at 14:05

I would say you are misunderstanding "SecondExact". Consider

Column[{
DateString[DateList[], {"Hour", ":", "Minute", ":", "Second", ".", "Millisecond"}],
DateString[DateList[], {"Hour", ":", "Minute", ":", "SecondExact"}]}]

12:02:48.748
12:02:48.748


This shows that "SecondExact" is just a shortcut for "Second", ".", "Millisecond". The documentation for DateString clearly states that "Millisecond" is only given to three digits. Therefore, giving seconds to more than 3 decimal place in a DataList isn't going produce any additional precision in the output from DateString. As to why DateString truncates, I would say that was a WRI developer's decision.

-
What does "typical" in the documentation mean? What is not "typical"? –  raxacoricofallapatorius Jan 8 '14 at 17:24
@raxacoricofallapatorius. Where in the docs is the "typical" are you referring to? –  m_goldberg Jan 8 '14 at 17:29
The comment above from @SjoerdC.deVries. –  raxacoricofallapatorius Jan 8 '14 at 17:31
@raxacoricofallapatorius. Ok. I've found the "typical". I don't think that doc item is relevant to your question. It refers to truncating time to whole seconds. The reasoning behind it, I would guess, is to make date strings look more like a digital clock displays. Clocks don't round seconds, they truncate them. Maybe the same readoning was applied to "Milliseconds", but who's to say? –  m_goldberg Jan 8 '14 at 17:39
Yet DateList is perfectly happy to give the time to the nearest 100ns as reported by the system clock: DateList[] -> {2014, 1, 8, 19, 55, 13.7832844}. If not a bug, it definitely seems like a stupid design decision to make DateString arbitrarily truncate in this way. –  Oleksandr R. Jan 8 '14 at 19:57