starred/asciinema

Fork 0

mirror of https://github.com/asciinema/asciinema.git synced 2026-04-25 07:55:51 +03:00

[GH-ISSUE #322] why is timestamp an integer? #214

New issue

Closed

opened 2026-02-25 20:33:05 +03:00 by kerem · 5 comments

kerem commented

2026-02-25 20:33:05 +03:00

Owner

Originally created by @kilobyte on GitHub (Sep 28, 2018).
Original GitHub issue: https://github.com/asciinema/asciinema/issues/322

While adding asciicast support to termrec, I noticed that the "timestamp" field is supposed to be an integer — inconsistently with "duration" and event timestamps. Is there a reason for this?

It doesn't matter much in most cases, as humans care mostly about recording date — but I can think of scenarios where not losing the precision would be nice.

(And my direct reason is that it's an odd case in the testsuite for round-tripping between ttyrec and asciicast :p.)

Originally created by @kilobyte on GitHub (Sep 28, 2018). Original GitHub issue: https://github.com/asciinema/asciinema/issues/322 While adding asciicast support to termrec, I noticed that the "timestamp" field is supposed to be an integer — inconsistently with "duration" and event timestamps. Is there a reason for this? It doesn't matter much in most cases, as humans care mostly about recording _date_ — but I can think of scenarios where not losing the precision would be nice. (And my direct reason is that it's an odd case in the testsuite for round-tripping between ttyrec and asciicast :p.)

kerem closed this issue

2026-02-25 20:33:05 +03:00

kerem commented

2026-02-25 20:33:05 +03:00

Author

Owner

@ku1ik commented on GitHub (Nov 16, 2018):

Hehe, I can see round-tripping problem :)

Yeah, the duration and event timestamps are floats, obviously.

The timestamp field is like you figured only something that would be turned into a date for humans, so we never thought we would need sub-second precision here. So no, there's no specific reason for this.

Since changing this would be a breaking change I'd rather not do this to v2. In practice it would probably be ok-ish, since neither asciinema play nor asciinema web player use this field for anything, and they're written in dynamic languages, which would handle that the same way. I said "ok-ish" as I don't know all the other tools people built around this format (I know of svg-term-cli, and a bunch of others), and whether they would work.

That could definitely be changed in v3 of the file format, although I don't see anything else which needs fixing in v2 to introduce v3 anytime soon.

@ku1ik commented on GitHub (Nov 16, 2018): Hehe, I can see round-tripping problem :) Yeah, the duration and event timestamps are floats, obviously. The `timestamp` field is like you figured only something that would be turned into a date for humans, so we never thought we would need sub-second precision here. So no, there's no specific reason for this. Since changing this would be a breaking change I'd rather not do this to v2. In practice it would probably be ok-ish, since neither `asciinema play` nor asciinema web player use this field for anything, and they're written in dynamic languages, which would handle that the same way. I said "ok-ish" as I don't know all the other tools people built around this format (I know of svg-term-cli, and a bunch of others), and whether they would work. That could definitely be changed in v3 of the file format, although I don't see anything else which needs fixing in v2 to introduce v3 anytime soon.

kerem commented

2026-02-25 20:33:05 +03:00

Author

Owner

@ku1ik commented on GitHub (Nov 17, 2018):

Actually it was supposed to be float: https://github.com/asciinema/asciinema/blob/develop/doc/asciicast-v2.md#duration

So it's been wrongly saved as integer :|

@ku1ik commented on GitHub (Nov 17, 2018): Actually it was supposed to be float: https://github.com/asciinema/asciinema/blob/develop/doc/asciicast-v2.md#duration So it's been wrongly saved as integer :|

kerem commented

2026-02-25 20:33:05 +03:00

Author

Owner

@kilobyte commented on GitHub (Nov 17, 2018):

termrec already accepts floats so that's nice. Should it produce them when writing an asciicast file?

@kilobyte commented on GitHub (Nov 17, 2018): **termrec** already accepts floats so that's nice. Should it produce them when writing an asciicast file?

kerem commented

2026-02-25 20:33:05 +03:00

Author

Owner

@ku1ik commented on GitHub (Nov 17, 2018):

@kilobyte yes, let's go with floats here, since that's what was the intent, and what the v2 format doc says. I'll fix that in asciinema recorder too.

@ku1ik commented on GitHub (Nov 17, 2018): @kilobyte yes, let's go with floats here, since that's what was the intent, and what the v2 format doc says. I'll fix that in asciinema recorder too.

kerem commented

2026-02-25 20:33:05 +03:00

Author

Owner

@ku1ik commented on GitHub (Nov 17, 2018):

@kilobyte ah, sorry. I looked wrong. duration (which I linked above by mistake) is supposed to be float but timestamp is documented as integer, like I wrote yesterday. Sorry for confusion. In that case I'd rather stay with int...

@ku1ik commented on GitHub (Nov 17, 2018): @kilobyte ah, sorry. I looked wrong. `duration` (which I linked above by mistake) is supposed to be float but `timestamp` is documented as integer, like I wrote yesterday. Sorry for confusion. In that case I'd rather stay with int...

kerem referenced this issue

2026-02-25 20:33:39 +03:00

[PR #214] [MERGED] Add fallback for JSONDecodeError #411

kerem referenced this issue

2026-03-15 11:14:24 +03:00

[PR #214] [MERGED] Add fallback for JSONDecodeError #1025