3 ms·

My primary codebase ingests data with a mix of seconds, milliseconds, and microseconds. We've held it at bay for a while, but it requires some mental overhead u

My primary codebase ingests data with a mix of seconds, milliseconds, and microseconds. We've held it at bay for a while, but it requires some mental overhead unless we've baked the unit into each variable name. We're likely to normalize on milliseconds, but at the same time, the implication of floating point arithmetic on all our μs numbers isn't ideal.

SideburnsOfDoom 4y ago
Durations aren't ints, so find or make a type suitable for storing them. For a similar issue (cache durations that were expressed as a mix of milliseconds, seconds, and minutes) I now insist that the framework type `TimeSpan` is used instead for expressing these durations - as that's exactly what it was designed for.
kevan 4y ago
In a similar vein, in the early days of launching Relay[1] I ended up spending a couple weeks in total squashing timestamp bugs. We were integrating with a few existing systems that used epoch seconds or milliseconds for timestamps and they usually didn't have a hint in the field name to tell what it was so it was really easy to miss in code reviews. Our problems were caused by a mix of serialization format (JSON numbers) and not always converting into the language's date/time types at the boundary (sometimes raw epoch seconds/millis were passed around layers of code and only parsed into a date for display. That created opportunities for misinterpretation at every function call. My general rules for non-performance critical code are 1. Always Parse into a first-class date/time/duration type at the serialization boundary. 2. Always use an unambiguous format (e.g. ISO-8601) for serialization It's not the most efficient but lets you rely on the type system for everything in your code and only deal with conversion at one place. [1] https://relay.amazon.com/ https://relay.amazon.com/

3 ms·

My primary codebase ingests data with a mix of seconds, milliseconds, and microseconds. We've held it at bay for a while, but it requires some mental overhead u

by paulirish 4y ago

SideburnsOfDoom 4y ago
Durations aren't ints, so find or make a type suitable for storing them. For a similar issue (cache durations that were expressed as a mix of milliseconds, seconds, and minutes) I now insist that the framework type `TimeSpan` is used instead for expressing these durations - as that's exactly what it was designed for.
kevan 4y ago
In a similar vein, in the early days of launching Relay[1] I ended up spending a couple weeks in total squashing timestamp bugs. We were integrating with a few existing systems that used epoch seconds or milliseconds for timestamps and they usually didn't have a hint in the field name to tell what it was so it was really easy to miss in code reviews. Our problems were caused by a mix of serialization format (JSON numbers) and not always converting into the language's date/time types at the boundary (sometimes raw epoch seconds/millis were passed around layers of code and only parsed into a date for display. That created opportunities for misinterpretation at every function call. My general rules for non-performance critical code are 1. Always Parse into a first-class date/time/duration type at the serialization boundary. 2. Always use an unambiguous format (e.g. ISO-8601) for serialization It's not the most efficient but lets you rely on the type system for everything in your code and only deal with conversion at one place. [1] https://relay.amazon.com/ https://relay.amazon.com/