@Bob@midwest.social to Lemmy Shitpost@lemmy.worldEnglish • 6 months agoEveryday, as an Americanmidwest.socialimagemessage-square323fedilinkarrow-up11.31Karrow-down146
arrow-up11.26Karrow-down1imageEveryday, as an Americanmidwest.social@Bob@midwest.social to Lemmy Shitpost@lemmy.worldEnglish • 6 months agomessage-square323fedilink
minus-square@dan@upvote.aulinkfedilink3•6 months agoSome ISO8601 formats are good, but some are unreadable (like 20240607T054831Z for date and time).
minus-square@zqwzzle@lemmy.calinkfedilinkEnglish6•6 months agoThe ones without separators tend to be for server/client exchange though.
minus-square@dan@upvote.aulinkfedilink2•6 months agoI agree but they’re hard to read at a glance when debugging and there’s lots of them :) Having said that, a lot of client-server communications use Unix timestamps though, which are even harder to read at a glance.
minus-square@zqwzzle@lemmy.calinkfedilinkEnglish1•edit-26 months agoAt least it’s human readable and not protobuf 😬 * though the transport channel doesn’t really matter it could be formatted this way anyhow.
minus-square@Shardikprime@lemmy.worldlinkfedilink1•6 months agoI mean I like this one without the separations
Some ISO8601 formats are good, but some are unreadable (like 20240607T054831Z for date and time).
The ones without separators tend to be for server/client exchange though.
I agree but they’re hard to read at a glance when debugging and there’s lots of them :)
Having said that, a lot of client-server communications use Unix timestamps though, which are even harder to read at a glance.
At least it’s human readable and not protobuf 😬 * though the transport channel doesn’t really matter it could be formatted this way anyhow.
I mean I like this one without the separations