Is it because there is no formal input argument?

It is because the output depends on something that is not an input, namely the current time.

Why is the actual time of day not treated as the “input to the function”

Because you didn’t pass it as a parameter. If you did pass it in as a parameter, the function would become an identity function on dates, which is pretty useless. The entire point of a Today() function is to output something that depends on an external and constantly changing value (time).

The advantage of pure functions is that their behavior is absolutely reproducible and deterministic, making it easy to have formal proofs and hard guarantees. They always do the same thing. Today() is pretty much the opposite: it always (allowing for time granularity) does something different.

sin(x) will always return the same value, as long as x stays the same. Today() could return different results over time because it depends on values outside of your control. For example, if something beyond the control of your program changes the system’s internal $current_datetime while your program is running, Today() will suddenly yield different results.

Today() is an impure function because its result is dependent upon something that you do not give it; specifically, the current system time. Therefore, its result is not deterministic when based only on the inputs provided at invocation.

A pure function would be int Add(int a, int b) {return a + b;}. The function works solely with what it is given, and uses no other external state data. The natural result of this is that you can Add(2,2) and get 4 from now until the end of time. In addition, because the function doesn’t change any external state (it has no “side effects”), Add()ing 2 and 2 from now until the end of time won’t change anything else in the system, unless you then assign the result of the function to a variable or otherwise use the value to update state (which is not an operation performed by the function itself). Virtually all classical mathematical operations are pure functions and can be implemented as such.

Today(), on the other hand, may produce the same value when called two times in a row, but not if called repeatedly for several days. This is because it is dependent on external state data which is not provided by you as a parameter to the function. As a result, it is impossible, within the boundaries of the program, to control the result of the Today() function. It will produce a given value on a given day, and will never produce that value on any other day, unless you change the system clock of the computer on which it is run (a change generally occurring outside the boundaries of the program).

An impure function is not necessarily a bad thing; impure functions are required, even in functional languages, to interact with anything outside the boundaries of the program, such as data stores, communication pipelines, UI displays, peripheral devices, etc. A program that does not do any of these things is a program that is sharply limited in its utility; I would even go so far as to call such a program trivial, as without any means to accept input or any avenue to inform you of its output, it might as well be doing nothing. Programs written in functional languages can have only the input provided by the runtime and produce an output reported to the runtime without any explicitly defined impure methods, but that’s because the runtime is abstracting away all these impure details of working within an imperfect computer system, so that the program itself can be structured in terms of a nested set of mathematical expressions that the runtime then evaluates given initial input.

It is simply a Very Good Thing to know which of the functions you are using are pure and which ones are not, so that you can make good decisions about how they are used. Impure functions, because they do things or are dependent on things that are not apparent from their usage, may behave unpredictably given only knowledge of the usage. Further knowledge of the purpose of the function, and thus what it needs from or does to external state, is required in order to place a system that uses it in a consistent state and thus to expect a deterministic result.

It seems fairly obvious that this function fails the first test of purity given at the very start of that page:

1. The function always evaluates the same result value given the same argument value(s). The function result value cannot depend on any
   hidden information or state that may change as program execution
   proceeds or between different executions of the program, nor can it
   depend on any external input from I/O devices.

Note that since it takes no arguments, there is only one possible set of argument values – the empty set. And this function can and does return different results for the same ‘argument value(s)’.

Furthermore, the function result value does depend on “hidden … state that may change as program execution proceeds”. So another failure.

() => 1 would be a pure function, since it always returns 1. Today() may return “Monday” or “Tuesday” or nearly any other value.

Another way to think of it is pure functions don’t depend on state. The world is typically considered state. You need to know the state of reality to know what day today is.

However you don’t need to know anything special about the state of the world to know what sin(x) is. And ever call to sin(x) for a given x will return the same value.

Date(timestamp) would be a pure function. Because of its idempotency. And because there would be no side-effect.

Today() can vary its result depending on when you call it. That’s what makes it impure. It’s not idempotent. It has no side-effect though, but that doesn’t make it pure.

Here’s a little pseudo code that I think of when discussing pure functions

newValue = Function();
while(true)
{
   oldValue = newValue;
   newValue = Function();
   assert( newValue == oldValue );
}

If that runs indefinitely and the can never trigger the assert, it’s a pure function. More so, if you have a function that uses args, then a little modification….

oldValue = Function( importantVariableToYourApp );
newValue = Function( importantVariableToYourApp );
assert( newValue == oldValue );

If you can use that after every variable assignment in your app, and it doesn’t change results in your app, and it can never fail the assert, then it is a pure function.

First, there is no such thing as a function without argument (or an array without indexes or a map without keys). It is the defining characteristic of a function to map one or more argument values to another value.

Hence, today is either not a function at all, hence no pure function.
Or we may interpret the syntax

today()

a bit so that it means

today   ()      -- today, applied to the value ()

In Haskell, for example, this would be valid:

data Day = Mon | Tue | Wed | Thu | Fri | Sat | Sun deriving Show
today :: () -> Day
today () = ....?
main = print (today())

because there is a type () with a single value ().

The question is only, how can today compute the day of the week, if it only has ()?
It is just not possible without reading the system timer, directly or via helper impure functions.

The system timer is an excellent example for global state.

The problem with today() is that it can yield a different result if called two or more times in a function.

Here is a code example, that could introduce a bug.

function doSomething(when)
{
     if(today() == when)
     {
           // open a resource or create a temp file.....
     }

     // do some other work

     if(today() == when)
     {
           // close the resource or delete temp file.....
     }
}

It’s possible in the above example. That the second if statement will not execute. Even if the first one did. Leaving a resource in a bad state.

To be a pure function, providing the same parameters must give the same result every time.

Each time we call Today(), we are providing it the same parameters (none), and yet not necessarily getting the same result (Monday, Tuesday, etc.).