When you create a new Standard Java Date object in each draw() cycle, and query its
timestamp via the method dateObject.getTime() the first returned timestamp is accurate, but
every further occurrence is false, as it is still equal to the first timestamp even though time
has elapsed in the meanwhile!

Possibly an interference with Core's month() day() hour() etc?

I added a code example. For debugging, consider these steps please:

1) Run the code example as it is. You will see that the output is constantly the same
timestamp, although time elapsed in the meanwhile.

2) Try to uncomment the "Pseudo query to a Processing core timing function". Sadly it also
did not help!

3) Finally comment the "Standard Java fails:" code sections (1 in draw, 1 in setup), and
uncomment the "Messy workaround:" code sections (1 in draw, 1 in setup). This produces no
Unix Epoch Timestamp, but at least a dirty timestamp, relative to the beginning of the
current month.

edit]
Code Example

Again, I'm all but certain you're just misunderstanding how the Java's Date
and Calendar classes work (I don't blame you, they're a mess), and also how
the delay() method works (read the reference for delay() carefully).

Also, we don't modify the "Date" class in any way--it's just the standard
Java Date class. So it's behavior is as-is from Java. Which is to say,
whatever it does is "correct".

From the code, it looks like you should be using System.currentTimeMillis()
(or the millis() method from Processing), since you're simply trying to
calculate elapsed time.

You are right with the assumption that I barely know Java.
But I read through the manpages for the required classes.

You falsely assumed that I only need to calculate elapsed time, and hence get along with
millis(). This is my mistake, because I did not mention the whole project, as I wanted to
keep the code example as short and abstracted as necessary, retrospectively maybe too
short.

I posted a project description of the "World Time Mosaic" into the exhibition section of the
forum: http://processing.org/discourse/yabb2/YaBB.pl?num=1248179250

The drawing program was realised with Processing:

Once all webcam pictures of one cyle are drawn onto the canvas, the canvas is saved to disk
by save() using the (messy workarround instead of the proper unix) timestamp as its
filename.

Later the screenshots are shown in a timelapse, if the determination of their timestamps
from their filenames showed that they are recent enough, which I determine by difference
calculations like "timeDuration = ageNow - ageLapseRecent", and then seeing whether
timeDuration is within certain thresholds.

I did not want to rely on the filesystem's timestamps and so I put them into the filename.
This live installation produces hundred thousands of files, as they are additionally kept for a
very long term timelapse movie, and the files may be moved through various disks and
filesystems, where they may loose that metadata, hence I store it in the filename.

Concerning the Java code: Every new draw() cycle I declare and create a Date object! Not
that I create it once globally, and use its method getTime() each time, then I would
understand why I get the same timestamp over and over again. But if a Date object is
declared and created each cycle from fresh, why does it always have the same timestamp? I
really don't understand it, and consider it as a faulty behaviour.

To put it short: It would be nice to have a way within Processing to create a timestamp, such
as a unix epoch timestamp (1970-2038), which I used both as a unique ID for the screenshots
plus also to determine its age. Equivalent so something like PHP's functions: time() and
microtime() and if do-able date() and strtotime().

*** This bug has been marked as a duplicate of 1291 ***

Again, there is no 'Date' bug in Processing, you simply need to read more
about how the Java Date functions work.

The following code calculates unix time on each trip through the draw loop:

void draw() {
int unixTime = (int) (new Date().getTime() / 1000L);
println(unixTime);
}

The rest of the Date and Calendar classes are wrappers around, or
implementations of, the C functions date(), strftime(), etc which are what
PHP makes use of.

Thanks for the solution!