Where and when you can, don't roll your own format. Use the existing libraries and routines, and/or use language-specific storage. Save for specific and rare

Where and when you can, don't roll your own format. Use the existing libraries and routines, and/or use language-specific storage. Save for specific and rare cases, neither time nor money seem (to me) appropriate in floating point. Whether or not the integer format (implicitly factional in most representations of time) is most appropriate, not all boxes have floating point, and floating point is not appropriate in various contexts on various boxes. Do either include the timezone or offset, or always operate in UTC. Avoid the TZ processing where you can, otherwise plan for and implement it. I've usually switched to 64-bit and longer for time values for most requirements; non-standard or "packed" formats or optimizing for storage have been more of a problem than a benefit, as compared with the savings from standard formats and libraries and the slight slightly increases memory use. Unless you're storing zillions of these things. OpenVMS uses centiseconds since 17-Nov-1858 in a long long; in a 64-bit value. There are conversions around in the Perl library, and I and others have posted C code for this. Unix uses a long or (increasingly commonly) a long long value since 1-Jan-1970 UTC. FWIW, the long (treated as a signed) overflows circa 19-Jan-2038 03:14:07. In various application environments, you will be stuck with your choice for a very long time. Plan for DST and switch-over cases. Pick wisely.