Todd Boyle and Jack Hassall, discussion April 1999 
over OMG's G/L specification:

On the naming and definition of dates in the General Ledger spec.
Todd Jack
Page 14 of the PDF file highlights a very important invariant, that every transaction in a General Ledger has
a date. However, I think the document and the invariant
itself, should be revised.
That's fine and that's why we have the OMG process - precisely so that various viewpoints can be considered and incorporated into the specification. Don't forget that what we're doing is "incremental development on a global scale", with increments happening every 12-18 months. This is a key point.
Accounting is a system of notation or semantics for recording a model or "map" of an underlying "territory" which has independent existence in the phenomenal universe. 

OMGs standard for a General Ledger should attempt to model the underlying reality of human commerce, difficult as that may be. 
Fine BUT(!) ... you try it! Many have, and many have failed. The semantics are one thing, but technology incompatibilities, unless eliminated, won't help you, even if you have the model and semantics and everything else nailed. So, the focus is on technology interoperability by providing an object oriented framework and interfaces for GL interoperability based on CORBA. Nobody can ever get this "right" so the GL spec is intentionally minimalist. The spec is revised and developed INCREMENTALLY. It's easy to forget that this is better than a waterfall approach. Developing a spec is "similar" (in some ways) to developing code. Take the waterfall approach at your peril, because it don't work. This is some of the thinking behind this.
The terms used in the document included "actual" date, physical date, "calendar" date, and entry date, before settling upon the terms "Logical Date" and "Physical Date" as the final requirement. These are not descriptive enough, especially for programmers without accounting backgrounds and accordingly might lead to some muddled design and usage.

Well, the date of execution of a commercial exchange, as required by GAAP,
is not a subtle or difficult concept. This date is a prominent feature 
of the conceptual space the software operates in. It's not asking much 
for programmers to understand it. 

Fair enough BUT; a) if you had two programmers, one with accounting experience and one without, which one would you pick? b) when writing a spec (or anything else for that matter) do you explain EVERYTHING on the assumption that a chimpanzee is going to be reading/implementing it?

Rhetorical questions of course because the answer is always "it depends". Issues such as these are what we call "contextual forces" and you have to resolve them as best as you can, in the full knowledge that they can't ever be fully resolved. So it's all a question of balance (no pun intended!)


The essential date to be recorded for GAAP is the date a transaction was executed between two parties in an exchange: "Transaction Execution date". 
Agreed. Logical or physical? though ... and what time is it on your heterogenous and distributed system? Logical or physical? It's not quite as straightforward as first meets the eye! 
The other nearly universally important date, in my opinion, is "System Posting Date" ie the date, minute and second an entry became part of the general ledger database. 

I realize that. But I really don't understand the exact meaning of the words logical and physical in this context. Here, read these

Are you saying these two terms are what most programmers will understand in addressing the precision problem, and the timezones problem?
If so, ok, that's fine with me. 

Say.... which date corresponds with the date in real world, when the transaction was consummated? 

Agreed but (see above) what time is it and what is the date? Is it at the client or is it at the server? We believe that you have to set this as some sort of policy, which is organisation-specific.