Take the 2-minute tour ×
Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

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?

share|improve this question
1  
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 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 at 6:37
2  
@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 at 13:51
1  
@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 at 14:05

1 Answer 1

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.

share|improve this answer
    
What does "typical" in the documentation mean? What is not "typical"? –  raxacoricofallapatorius Jan 8 at 17:24
    
@raxacoricofallapatorius. Where in the docs is the "typical" are you referring to? –  m_goldberg Jan 8 at 17:29
    
The comment above from @SjoerdC.deVries. –  raxacoricofallapatorius Jan 8 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 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 at 19:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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