4 ms·

I wouldn't use an int. Some things use milliseconds since 1970 instead of seconds to get sub-second precision without involving double, and you need to read the

I wouldn't use an int. Some things use milliseconds since 1970 instead of seconds to get sub-second precision without involving double, and you need to read the docs to understand what is expected. Or you can just pass a DateTime object standard for the language if running in a single binary, or something like ISO 8601 when there's a network in between. Databases can often store DateTime objects sanely.

targafarian 3y ago
64 bit unsigned integer nanoseconds gets you out to 584 years (that's the year 2554 if you're using the Unix epoch). That's good enough for me to use universally for passing times around in the internals of my code. User input and output are going to and from that representation. Half as many, of course, if you use a signed integer. If you don't need nanoseconds, then use microseconds and you get 292 thousand years to work with. Integers are just a bit easier than floats for timestamps in my experience (e.g., comparing floats to one another is fraught and you'll be fighting this at every turn in your code).
- deleted 3y ago
  [deleted]
- zokier 3y ago
  tbh using signed 64 bit microseconds with ISO-8601 0000-01-01 as epoch has certain elegance to it and should cover fairly wide range of use-cases.
- Kwpolska 3y ago
  You have standardized on int64 = nanoseconds. Libraries you use might have standardized on int64 = milliseconds, int64 = seconds, double = seconds, or the preferred DateTime class/struct of your programming language — even the C standard library has `struct tm` [0]. If you’ve wrapped your int64 in some struct/class/type-alias-without-automatic-downcasting, it might be fine. But if you haven’t, you might end up mixing the different scales, or littering the code with pointless conversions to and from the standard DateTime class/struct. [0] https://www.gnu.org/software/libc/manual/html_node/Broken_002ddown-Time.html https://www.gnu.org/software/libc/manual/html_node/Broken_00...
zokier 3y ago
> Some things use milliseconds since 1970 instead of seconds to get sub-second precision without involving double Or be like JS which uses both floats and milliseconds as its date format. That to me feels like taking worst parts of every option. But then, making fun of JS is like shooting fish in the barrel
- Kwpolska 3y ago
  (This is a side effect of JS not having a real integer type.)

targafarian 3y ago

64 bit unsigned integer nanoseconds gets you out to 584 years (that's the year 2554 if you're using the Unix epoch). That's good enough for me to use universally for passing times around in the internals of my code. User input and output are going to and from that representation. Half as many, of course, if you use a signed integer. If you don't need nanoseconds, then use microseconds and you get 292 thousand years to work with. Integers are just a bit easier than floats for timestamps in my experience (e.g., comparing floats to one another is fraught and you'll be fighting this at every turn in your code).

deleted 3y ago
[deleted]
zokier 3y ago
tbh using signed 64 bit microseconds with ISO-8601 0000-01-01 as epoch has certain elegance to it and should cover fairly wide range of use-cases.
Kwpolska 3y ago
You have standardized on int64 = nanoseconds. Libraries you use might have standardized on int64 = milliseconds, int64 = seconds, double = seconds, or the preferred DateTime class/struct of your programming language — even the C standard library has `struct tm` [0]. If you’ve wrapped your int64 in some struct/class/type-alias-without-automatic-downcasting, it might be fine. But if you haven’t, you might end up mixing the different scales, or littering the code with pointless conversions to and from the standard DateTime class/struct. [0] https://www.gnu.org/software/libc/manual/html_node/Broken_002ddown-Time.html https://www.gnu.org/software/libc/manual/html_node/Broken_00...

zokier 3y ago

> Some things use milliseconds since 1970 instead of seconds to get sub-second precision without involving double Or be like JS which uses both floats and milliseconds as its date format. That to me feels like taking worst parts of every option. But then, making fun of JS is like shooting fish in the barrel

Kwpolska 3y ago
(This is a side effect of JS not having a real integer type.)