Generating Current Timestamp with microsecond with "SSSSSS" - Works but with padding three zeroes

[authorjapps]

Actual

"timeNow":"${LOCAL.DATETIME.NOW:yyyy-MM-dd'T'HH:mm:ss.SSSSSS}Z"
Generates:
“2023-12-06T14:17:47.738000” 🔴  <— Always generates with “000” padding, which is not exactly correct

"timeNow":"${LOCAL.DATETIME.NOW:yyyy-MM-dd'T'HH:mm:ss.nnnnnnnnn}Z”
“2023-12-06T14:17:47.738553101” 🟢  <— works as expected.

Expected

"timeNow":"${LOCAL.DATETIME.NOW:yyyy-MM-dd'T'HH:mm:ss.SSSSSS}Z"
Should generates:
“2023-12-06T14:17:47.738109” 
Or
“2023-12-06T14:17:47.738125” 
Or
“2023-12-06T14:17:47.738775”
Etc

---

Potential Fix

• If java8 has no outofthebox date/time function to generate this, then another PH(placeholder)-Token could be implemented to solve this.
• Or suggest any other idea 💡

[abhija77]

Hi,

I would like to contribute to your project, to gain in experience.
How can i take this issue :) ?

Ayoub

[nirmalchandra]

Hi,

I would like to contribute to your project, to gain in experience. How can i take this issue :) ?

Ayoub

@abhija77 👋 , can you have a look at the CONTRIBUTING and BUILDING please.
That should give you some start point to crack on.

[brian6484]

Hello :) I am new to open source contribution and came across this issue, which I would like to solve. But I just have a few questions.

1. What test do I need to run to see this timeNow field being printed out in the log? I searched for this "timeNow" field within source code but is it just variable name or an actual field name in the log? I saw that it is the request and response time stamps that take the value from this timeNow field variable and is built to make CoreLogger. So is the name of this "timeNow" field accurate or am I missing something?

2. I am thinking of using Java 8's DateTimeFormatter to format to string first and convert it back to localdatetime type. Is this idea viable?

[luke-zhou]

I think this is the issue with Java 8, the LocalDateTime is actually returning the clock value, which in Java 8 is based on System.currentTimeMillis()(in most operating system), and this is the reason it only returns 3 digits.
and also, when I was testing:

"timeNow":"${LOCAL.DATETIME.NOW:yyyy-MM-dd'T'HH:mm:ss.nnnnnnnnn}Z”
“2024-05-31T17:29:06.979000000” 🟢  <— This return is different from yours, I dont know if I missed anything here.

I'm also uncertain if this level of accuracy is necessary. Since the value is used for comparison with API returns, the nanoseconds (and even milliseconds) might not align with the actual return values. To me, this seems unnecessary.

This is just my perspective, and I could be mistaken.

Cheers,

Actual

"timeNow":"${LOCAL.DATETIME.NOW:yyyy-MM-dd'T'HH:mm:ss.SSSSSS}Z"
Generates:
“2023-12-06T14:17:47.738000” 🔴  <— Always generates with “000” padding, which is not exactly correct

"timeNow":"${LOCAL.DATETIME.NOW:yyyy-MM-dd'T'HH:mm:ss.nnnnnnnnn}Z”
“2023-12-06T14:17:47.738553101” 🟢  <— works as expected.

Expected

"timeNow":"${LOCAL.DATETIME.NOW:yyyy-MM-dd'T'HH:mm:ss.SSSSSS}Z"
Should generates:
“2023-12-06T14:17:47.738109” 
Or
“2023-12-06T14:17:47.738125” 
Or
“2023-12-06T14:17:47.738775”
Etc

Potential Fix

• If java8 has no outofthebox date/time function to generate this, then another PH(placeholder)-Token could be implemented to solve this.
• Or suggest any other idea 💡

[nirmalchandra]

I think we can close this issue.

As you suggested, we can get almost the same result by this:
Instead of "timeNow":"...'HH:mm:ss.SSSSSS}Z", the below can be used to get all the digits populated:

"timeNow":"...'HH:mm:ss.SSS}123Z"

(... SSS}123 or SSS}456 etc... where SSS will resolve to random timelapsed mili-sec always and
then, 123 or 456 will be static, but together the whole number will be a random and unique and can be treated like nano-sec)