Re:MessagePack: like JSON, but fast and small
by Myrmornis on Wednesday March 11, 2020 @12:52PM
(#22547326)
Could you add something saying explicitly what a timestamp _is_ under your terminology? Is it an integer offset from the UNIX era start?
Re:MessagePack: like JSON, but fast and small
by lokedhs on Wednesday March 11, 2020 @02:22PM
(#22548662)
It's an abstract concept. It's nothing more than a given point in time.
How you represent it doesn't change the definition. It could be stored as the number of seconds since some arbitrary point in time, such as Unix timestamp, or a Julian timestamp.
Or, it could be a given time and date combination with some fixed point of reference, such as UTC. I'm sure we all have favourite ways of representing timestamps.
Re:MessagePack: like JSON, but fast and small
by Myrmornis on Thursday March 12, 2020 @11:50AM
(#22558061)
Ok, one thing — perhaps not the most important — is that “timestamp” is a very unfortunate terminology for the abstract concept you describe. The word timestamp very much suggests that it’s referring to an explicit representation of some sort. “timepoint” would be much better for what you’re talking about. Not a criticism of you of course! I mostly write python at work so I rarely am directly exposed to the integer offset values, but I know many people use the word “timestamp” to refer to that integer, as opposed to a formatted string. Which also seems like unfortunate terminology, since what is a stamp if not formatted?
Re:MessagePack: like JSON, but fast and small
by foepys on Thursday March 12, 2020 @12:36AM
(#22553815)
You are assuming that timezones don't change ever in relation to UTC. This is wrong. Timezones change all the time.
When I set an alarm for any time in CEST in 2022 and convert this to UTC before saving it, it will very likely ring at the wrong time, simply because CEST will probably not exist by then and be replaced by CET due to the EU getting rid of DST.
A timestamp is a point in time, and is the same everywhere (excluding relativistic effects).
What you describe is definitely a valid use case (and having developed software that programs hardware that is controlled by a calendar, I have painful experience in this). However, it's not a timestamp. I'd call it time-of-day or wallclock. Some systems like SQL refers to it as simply "date" and "time". Whatever you prefer to call it, it's not a timestamp.