Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Unixseconds serializer #181

Open
hfhbd opened this issue Jan 16, 2022 · 6 comments
Open

Add Unixseconds serializer #181

hfhbd opened this issue Jan 16, 2022 · 6 comments
Labels
formatters Related to parsing and formatting

Comments

@hfhbd
Copy link
Contributor

hfhbd commented Jan 16, 2022

Many APIs return a unix timestamp, the seconds from the epoch as Long.
Although the serializer is easy to create, it could be provided.

public object InstantUnixSecondsSerializer : KSerializer<Instant> {
    override val descriptor: SerialDescriptor = PrimitiveSerialDescriptor("Instant", PrimitiveKind.LONG)

    override fun deserialize(decoder: Decoder): Instant = Instant.fromEpochSeconds(decoder.decodeLong())

    override fun serialize(encoder: Encoder, value: Instant) {
        encoder.encodeLong(value.epochSeconds)
    }
}
@dkhalanskyjb
Copy link
Contributor

This serializer has the unpleasant property of losing some information: it doesn't preserve the nanoseconds. Making it preserve the nanoseconds would lead to recreating the InstantComponentSerializer—maybe use that? If the nanosecond component is zero, it's omitted, like in {"epochSeconds":1642418590}.

@hfhbd
Copy link
Contributor Author

hfhbd commented Jan 17, 2022

Sorry, with APIs I mean 3rd party JSON (REST) APIs which returns something like this:

{
    "timestamp": 123456789
}
@Serializable
data class Result(@Serializable(with=InstantUnixSecondsSerializer::class) val timestamp: Instant)

If you are able to change the json format, you could use instead InstantComponentSerializer(or even better ISOSerializer...), but often you can't change it.

@dkhalanskyjb dkhalanskyjb added the formatters Related to parsing and formatting label Jan 17, 2022
@ilya-g
Copy link
Member

ilya-g commented Jan 17, 2022

I believe it would be reasonable to provide such serializer out-of-the-box if the unix seconds timestamps are indeed widespread in third-party json formats. The question is how to estimate how widespread they are, and whether we need a unix-millis-as-long serializer in addition to the proposed one.

@hfhbd
Copy link
Contributor Author

hfhbd commented Jan 17, 2022

Just for the record: Unix timestamp does not include milliseconds by definition: https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html A.4.16

@weickmanna
Copy link

It seems to be more wide-spread in the finance sector. So without doing deep research, I guess one can say the format is used often enough to warrant providing it out of the box.
These APIs that I am working with are using the epochMillis however. So if opening this box, consider adding both InstantUnixSecondsSerializer and InstantUnixMillisSerializer.

@zsmb13
Copy link

zsmb13 commented May 8, 2024

Interestingly, the YouTrack APIs also use Long unix timestamps for fields like created and updated (with milliseconds, not seconds).
https://www.jetbrains.com/help/youtrack/devportal/api-entity-Issue.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
formatters Related to parsing and formatting
Projects
None yet
Development

No branches or pull requests

6 participants
@ilya-g @weickmanna @zsmb13 @hfhbd @dkhalanskyjb and others