fix: modify to run with @pinojs/dateformat

[Uzlopak]

@jsumners
I am not maintainer here, so I could not push into your branch.

[Uzlopak]

Basically SYS: is the same as GMT. I could just modify our dateformat to even avoid that slice(4) call.

[mcollina]

looks good!

[jsumners]

Are there any technical reasons @pinojs/dateformat is not a drop-in replacement for dateformat?

[Uzlopak]

@jsumners

No, it was an accidental typo.

[jsumners]

@jsumners

No, it was an accidental typo.

Sorry. I don't follow. I expected the only changes necessary would be replacing every occurrence of require('dateformat') with require('@pinojs/dateformat'). That does not seem to be the case. Are there technical reasons for this?

[Uzlopak]

No, there are no technical reasons. I made a mistake, by making a capital F instead of a lowercase f. I will fix it. I am just currently commuting... I provide you with a fix in fee hours

[Uzlopak]

@jsumners
done

[Uzlopak]

@mcollina
@jsumners

Please review again.

[mcollina]

lgtm once our dateformat method hits 1.0.0

[Uzlopak]

Changing this PR to draft. Will get back to it some day.

[jsumners]

I'm going through our modules in alphabetical order and getting the updated for pino@10/dropping Node v18. I've made it down to pino-caller, so I'm still a ways away from getting to this one. But I'd like to see this get resolved before I get there. Do you have time to address this?

[Uzlopak]

yes, i will take care of it today.

[Uzlopak]

@jsumners

wdyt of this in combination with pinojs/dateformat#5 `

[Uzlopak]

So.. modified this PR to use only the improved dateformat function and not the DateFormatter from pinojs/dateformat.

It is not the implementation for high performance, as for that you should instantiate the dateformatter. But this change should be already faster than the original dateformat function.

If we one day have interest in more performance, we then only need to use DateFormatter.