3 ms·

Best code strategy here is twofold. 1. Maximize the code context where date/time is represented as a simple count of Unix epoch seconds. 2. Never pass calenda

Best code strategy here is twofold. 1. Maximize the code context where date/time is represented as a simple count of Unix epoch seconds. 2. Never pass calendar/clock representations through API methods. 3. Always pass a timezone to methods that require it. 4. Counting, like time, is hard. The only contexts I see where calendar/clock representation are needed are: - Accept calendar/clock info from the user or external data sources. - Present calendar/clock info to the user or external data sources. - Internal "calendar aware" operations (find the Unix epoch second count "one month from now"). These all require a timezone to be specified. They may still be a mess internally but their operation is unambiguous. They may use imperfect data types like datetime but the issues of these data times are confined to their internal code context.

pepoluan 3y ago
The problem with Unix Epoch is that it began in 1970. There are applications where you need dates before 1970 and that starts to get hairy.
- magicalhippo 3y ago
  Signed integers exist. What is hairy about using them?
- zokier 3y ago
  Bigger problem of 1970 epoch is that the 1970-1972 period was confusing time for UTC; having the epoch at 1972 would be arguably much cleaner Fun excerpt from Wikipedia: > As an intermediate step at the end of 1971, there was a final irregular jump of exactly 0.107758 TAI seconds, making the total of all the small time steps and frequency shifts in UTC or TAI during 1958–1971 exactly ten seconds, so that 1 January 1972 00:00:00 UTC was 1 January 1972 00:00:10 TAI exactly, and a whole number of seconds thereafter. At the same time, the tick rate of UTC was changed to exactly match TAI. I'll leave it as exercise to the reader to think of all the implications of whatever timesteps and tickrate shifts that happened pre-1972.
zokier 3y ago
> 1. Maximize the code context where date/time is represented as a simple count of Unix epoch seconds. Either your values will be different from UNIX timestamp (and you need to write your own conversion functions), or they are not simple count of seconds and will have ambiguities. Neither is not great situation.
Kwpolska 3y ago
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...
winternewt 3y ago
The problem with Unix timestamps is that it doesn't take leap seconds into account, which makes it ambiguous during a leap second and makes it messy to compute the duration between two timestamps. I think you're on the right track but a timestamp should only count the actual number of seconds that have passed, not some half-measure that tries to align with the rotation of the earth.
- frumiousirc 3y ago
  Ah, thanks. I didn't know that Unix time is discontinuous over leap seconds! I had thought just the opposite. And now I understand some system failures I know about that occurred during leap seconds but which I've never understood. I think to handle leap seconds, one must carry around both Unix timestamp and a "leap delta". The timestamp is needed to convert to calendar/clock representation and the "leap delta" is needed to compare two Unix timestamps for actual elapsed time. What a headache!

pepoluan 3y ago

The problem with Unix Epoch is that it began in 1970. There are applications where you need dates before 1970 and that starts to get hairy.

magicalhippo 3y ago
Signed integers exist. What is hairy about using them?
zokier 3y ago
Bigger problem of 1970 epoch is that the 1970-1972 period was confusing time for UTC; having the epoch at 1972 would be arguably much cleaner Fun excerpt from Wikipedia: > As an intermediate step at the end of 1971, there was a final irregular jump of exactly 0.107758 TAI seconds, making the total of all the small time steps and frequency shifts in UTC or TAI during 1958–1971 exactly ten seconds, so that 1 January 1972 00:00:00 UTC was 1 January 1972 00:00:10 TAI exactly, and a whole number of seconds thereafter. At the same time, the tick rate of UTC was changed to exactly match TAI. I'll leave it as exercise to the reader to think of all the implications of whatever timesteps and tickrate shifts that happened pre-1972.

zokier 3y ago

> 1. Maximize the code context where date/time is represented as a simple count of Unix epoch seconds. Either your values will be different from UNIX timestamp (and you need to write your own conversion functions), or they are not simple count of seconds and will have ambiguities. Neither is not great situation.

Kwpolska 3y ago

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...

winternewt 3y ago

The problem with Unix timestamps is that it doesn't take leap seconds into account, which makes it ambiguous during a leap second and makes it messy to compute the duration between two timestamps. I think you're on the right track but a timestamp should only count the actual number of seconds that have passed, not some half-measure that tries to align with the rotation of the earth.

frumiousirc 3y ago
Ah, thanks. I didn't know that Unix time is discontinuous over leap seconds! I had thought just the opposite. And now I understand some system failures I know about that occurred during leap seconds but which I've never understood. I think to handle leap seconds, one must carry around both Unix timestamp and a "leap delta". The timestamp is needed to convert to calendar/clock representation and the "leap delta" is needed to compare two Unix timestamps for actual elapsed time. What a headache!