DATETIME truncation

[jymcheong]

Version: 25.1.1 release docker container

Steps to reproduce

CREATE VERTEX TYPE  Alert IF NOT EXISTS;
CREATE PROPERTY Alert.timestamp IF NOT EXISTS DATETIME;
insert INTO Alert content {type:'IT', timestamp: "2025-02-06 06:46:01"}

Expected: timestamp = 2025-02-06 06:46:01

Actual: timestamp showing YYYY-MM-DD format

Other notes

• Observed from configuration dump arcadedb.dateTimeFormat = yyyy-MM-dd HH:mm:ss
• even with insert into Alert CONTENT { type:'IT', timestamp = "2024-12-05 22:56:02"}, it still ends up truncating time portion
• default sysdate('YYYY-MM-DD HH:MM:SS') was taken from arcadeDB docs website, it ends up setting default on arcadeDB UI is showing today's date instead of sysdate, seen that in OrientDB before.

[jymcheong]

Same test case on 25.1.1-SNAPSHOT, it does NOT truncate.

[jymcheong]

[jymcheong]

After reading https://docs.arcadedb.com/#Managing-Dates, I noted there's

alter database arcadedb.dateTimeImplementation java.time.LocalDateTime

After incorporating it into docker compose, there's no longer truncation:

[gramian]

@lvca Maybe I should add an explicit note to the docs? @jymcheong where in the docs would you look first to find such info?

@jymcheong can this issue be closed then?

[jymcheong]

@gramian the info was under Managing Date section.

As for closing, It’s going to be a problem for users who have DATETIME type properties if they didn’t explicitly set that JAVA OPT for docker run or compose.

In fact prior to answering this, we were testing it under WSL2 container, same problem.

[jymcheong]

@gramian

I downloaded 25.1.1 tar & ran it on host directly, time truncated:

but after I modified bin/server.sh to include -Darcadedb.dateTimeImplementation=java.time.LocalDateTime as one of the options. Then it shows the proper date time format.

That means someone who upgrades from 24 to 25.1.1-SNAPSHOT, to 25.1.1 release, will end up with a surprise like what we encountered, our UI timeline suddenly started to show only dates. Because we have some demo to show soon, I had to dig into the manual to find workarounds.

So I am not sure if this should be closed.

[jymcheong]

@gramian

It is not explicitly found in the manual, but based on that ALTER statement, I ported it to docker compose & it worked. That is more like a workaround. 24 to 25.1.1-SNAPSHOT didn't exhibit this behavior. Something changed in 25.1.1 release & it became like this.

I upgraded to 25.1.1 because it resolved #1898

[gramian]

Checking SELECT FROM schema:database, I get the defaults:

[...,
 { "key":"arcadedb.dateImplementation","value":"java.util.Date","description":"Default date implementation to use on deserialization. By default java.util.Date is used, but the following are supported: java.util.Calendar, java.time.LocalDate","overridden":false,"default":"java.util.Date"},
 {"key":"arcadedb.dateFormat","value":"yyyy-MM-dd","description":"Default date format using Java SimpleDateFormat syntax","overridden":false,"default":"yyyy-MM-dd"},
...]

Trying to change the dateFormat:

ALTER DATABASE `arcadedb.dateFormat` 'yyyy-MM-dd HH:mm:ss';

as described in the docs, leads to the error:

Error on command execution (PostCommandHandler): User 'root' is not allowed to update database settings

(This error is unrelated though)

[gramian]

Also sysdate seems to ignore the formatting parameter, see #1958

[gramian]

OK, more info:

The error described above with ALTER DATABASE happens only in container, not on bare metal.

Using:

ALTER DATABASE `arcadedb.dateFormat` 'yyyy-MM-dd HH:mm:ss';

makes SELECT sysdate() work as expected.

ALTER DATABASE `arcadedb.dateTimeFormat` 'yyyy-MM-dd HH:mm:ss';

has no effect. I will add this effect to the docs.

[gramian]

@jymcheong as another workaround you can start the ArcadeDB server with an option like "-Darcadedb.dateFormat=yyyy-MM-ddTHH:mm:ss", then sysdate() adapts. Note I am using dateFormat, not dateTimeFormat.

[jymcheong]

@gramian & @lvca thanks!

[gramian]

Something is still off. The workaround above seems only to work if the database is created afterwards (I guess this is expected?).

[jymcheong]

Something is still off. The workaround above seems only to work if the database is created afterwards (I guess this is expected?).

@gramian yes, the same observation at my end. Had to drop the DB & create then somehow sysdate() and those test statements will start to run correctly.