Question: What is the motivation for using ISO strings instead of UTC epoch/unix Timestamps

[MV-GH]

Question

What is the motivation for using ISO strings instead of UTC epoch Timestamp?

String vs 64 bit integer "2024-04-27T03:53:51.930329Z" vs 1714190031930

Benefits unix timestamp:

• Shorter (8B vs 27B)
• Faster de/serialization
• Universal
• Better support

[dessalines]

We use TimestampTz for all the postgres time columns, which diesel maps to chrono::DateTime. Serde by default serializes those as RFC 3339 strings.

Serde does support serializing those as unix millis or micro timestamps using serde_with. I'd be in favor of this, but for such a big breaking change, we'd def need to hear from everyone else.

• Serde Chrono
• Diesel mappings

[MV-GH]

Yeah it's big change, but other then the initial hurdle I don't see any drawbacks. Would love some more opinions though.

[Nothing4You]

I assume this is about Lemmy's API only?

The obvious drawback is human readability, but this only really impacts developers. You can't easily tell the dates anymore by looking at API responses, and developers effectively have to convert these numbers to a human readable format, while RFC 3339 is already human readable, and can be displayed directly depending on the use case.

[MV-GH]

Yes only about the API.

You can't easily tell the dates anymore by looking at API responses,

If looking at raw JSON response sure, but takes only few seconds to find out. If using a "lemmy-api-client" their toString implementation can easily handle it.

effectively have to convert these numbers to a human readable format, while RFC 3339 is already human readable, and can be displayed directly depending on the use case.

I don't think there is any client out there that displays it as such. It is not very user friendly. While clients now have to do special work to parse this ISO date. But every stdlib has support for unix timestamp.

Other then displaying timestamps, the most common other use case is to compare them with other timestamps. Unix timestamps can be compared directly and do not need to be even interpreted. Making it much easier and efficient.

If we were to change, I would recommend millis.

[dullbananas]

I think unix timestamps are better, but I'm not sure whether or not the mess of a breaking change is worth it

[MV-GH]

Could do it with v4 API

[Nutomic]

Unix timestamps dont include timezone, so this would risk reintroducing the problem which was fixed by https://github.com/LemmyNet/lemmy/pull/3496. Also API responses can be gzipped, then there should be no significant size difference. And ISO timestamps are very widely supported.

[dullbananas]

Postgresql "timestamp with time zone" is actually just a UTC timestamp

https://www.postgresql.org/docs/current/datatype-datetime.html

https://stackoverflow.com/a/75670174/11041613

[MV-GH]

Unix timestamps dont include timezone, so this would risk reintroducing the problem which was fixed by https://github.com/LemmyNet/lemmy/pull/3496.

No, it won't. Unix timestamp is in UTC. The problem with naiveDateTime is that you returned their local time but without the timezone information. While Unix timestamp would return the time in UTC.

Also API responses can be gzipped, then there should be no significant size difference. And ISO timestamps are very widely supported.

Gzip isn't magic, Bigger input will still result in a bigger output.

I just find it silly to use a format that is less supported and less efficient in every factor.

[dessalines]

Using chrono/serde ts_microseconds would be an exact fit.

I'm also wondering about potential serialization issues with other federated services tho.

[MV-GH]

I would recommend millis over micros. Much more popular (in my experience)

This is only about the Lemmy API. I don't know about the requirements of Apub spec,

[Nutomic]

Too much effort for very little benefit.

[dessalines]

If someone wanted to take this on, I wouldn't be opposed to re-opening and assigning it to them. But ya I agree, it's a lot of a effort and a major breaking change.