2
$\begingroup$

Below is an expression that (for me) evaluates differently on the two most recent versions of Mathematica. Can others confirm this? It’s either a bug in v13.1.0, or my installation is faulty (which I doubt). Note: I’m running on Apple Silicon; YMMV on other processors.

Row[{First[Map[AbsoluteTime[FileDate[#]]&, {FileNames[][[1]]}]], "   ", $Version}]

In both cases, the first item in the Row is a recent date expressed in seconds since the start of the last century; v13.0.1 returns it as an Integer and v13.1.0 returns it as a Real.

Earlier this month, I posted a query entitled "Function returns a list of 3 integers in v13.0.1, but raises an error in v13.1.0 by returning a list of length 5"; I was criticized (correctly) for not providing sample code, and I deleted my query as suggested. After severe pruning of the notebook (over half a megabyte in size), I believe I have found the malfunction's source, and have condensed it into a one-liner. I think the above expression will run in any notebook in any folder.

Improve this question
$\endgroup$
1
  • $\begingroup$ You can simplify this further to Head@ AbsoluteTime@ FileDate@ First@ FileNames[]. I can confirm that MMA 12.3.1 on Win10-64 returns Integer and version 13.1.0 on Linux x86-64 (the cloud) returns Real. $\endgroup$
    – MarcoB
    Jul 19, 2022 at 19:47

1 Answer 1

Reset to default
1
$\begingroup$

After a couple of trials, the difference is how AbsoluteTime interprets a DateObject containing machine-precision numbers.

On my laptop running MMA 12.3.1 on Win10-64, the two following expressions both return an integer:

AbsoluteTime@ DateObject[{2021, 12, 3, 12, 22, 57.}, "Instant", "Gregorian", -5.]
AbsoluteTime@ DateObject[{2021, 12, 3, 12, 22, 57}, "Instant", "Gregorian", -5.]

(* 3847522977 for both *)

Note that the only difference is in the seconds specification: the first being machine-precision, the second being an exact number.

On the cloud, running MMA 13.1.0 for Linux x86 (64-bit), the two expressions return different results:

AbsoluteTime@ DateObject[{2021, 12, 3, 12, 22, 57.}, "Instant", "Gregorian", -5.]
(* Out: 3.84752*^9 *)

AbsoluteTime@ DateObject[{2021, 12, 3, 12, 22, 57}, "Instant", "Gregorian", -5.] 
(* Out: 3847522977 *)

The result on the newer version seems more consistent with its input, to be honest. In either case, I was unable to find an indication in the docs on whether AbsoluteTime has been recently updated, or what the expected behavior should be.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Depending on its argument, it seems AbsoluteTime (on either version) sometimes returns an Integer, sometimes a Real. I see no reason for the inconsistency. $\endgroup$
    – James Stein
    Jul 19, 2022 at 20:16
  • $\begingroup$ @JamesStein I would expect functions in MMA to behave that way though: Sin[0] returns 0, an Integer; whereas Sin[0.] returns 0., a Real. It is perhaps the fact that FileDate returns a machine-precision DateObject that is more unexpected to me. $\endgroup$
    – MarcoB
    Jul 19, 2022 at 20:19
  • $\begingroup$ Seeing no reason for the inconsistency doesn't necessarily mean it's a bug. The documentation makes several comments about precision and representation being system dependent. The only guarantee I see is "AbsoluteTime[] is always accurate down to a granularity of $TimeUnit seconds...". It even explicitly says "Noninteger values of d, h, m, s can also be used". So, I think assuming that it'll always be an Integer or always a Real is inappropriate. $\endgroup$
    – lericr
    Jul 19, 2022 at 21:18
  • $\begingroup$ It seems to me that this is more attributable to a change in the behavior of DateObject, rather than to a change in AbsoluteTime. $\endgroup$
    – CA Trevillian
    Jul 19, 2022 at 22:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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