3 ms·

the question is what format. what you're really doing is storing a slash-separated CSV of integers with only one entry, and storing a set of integers is what ma

the question is what format. what you're really doing is storing a slash-separated CSV of integers with only one entry, and storing a set of integers is what many old systems already did. the real solution is to store 64-bit seconds (or perhaps 96-bit microseconds, if you need precision) since some epoch, like jan 1st 1970. it's a simple integer that monotonically increases with a defined starting point. you can't get any more simple or reliable than that. the unix time stamp was a wonderful solution, they just chose to use too few bits for how long their system would end up living. 64-bit integer seconds will last something like 42x the age of the universe, so that ought to cover things.

mjevans 3y ago
Dates / timestamps fail to capture an 'event'. At best they are a partial event specification with the assumption that they are converted correctly to an assumed increment along a single time scale. Event specification is a very complex and politically entwined idea. This involves not just a frame of reference for the time, but also a location within which that time should make sense. Otherwise it is impossible to derive the correct rule-set for evaluating the human interpreted value of that moment. An alternative which might make sense is to force people to specify which ruleset they desire with the offset value within said ruleset. Sadly, my preferred representation of time isn't expressed in either of the popular standards (RFC 3339 or ISO-8601). https://ijmacd.github.io/rfc3339-iso8601/ https://ijmacd.github.io/rfc3339-iso8601/ RFC 3339 gets closet to my preference with: 2023-09-17 23:51:41Z However these are examples of what I'd prefer to see: * 2023-09-17 23:51:41 Z UTC * 2023-09-17 16:51:41 PST8PDT USA/WA/Seattle * 2023-09-17 16:51:41 PST8PDT Canada/British Columbia/Vancouver Note: At the moment Vancouver BC and Seattle WA happen to observe the same time offset but are in different political locales with different DST shift times. I'm not sure if it's still correct to call either timezone PST8PDT... that may imply the USA/CA/Los Angeles. Time would be expressed numerically 'large endian first' format, with zero or one punctuation element between units, preferably expressed with individual units matching the most correct (easiest for a human to read what they expect) value at a glance. This means - (or no separation) for dates, and : (or no separation) for HMS. (Space) or _ (Underscore) are preferable for between units. The timezone 'name' follows the smallest unit of time, which is itself followed by the reference city. Implicitly events in the past were accurate at the time they were encoded, while events in the future might need re-validation and conversion if the rules have changed. Though it would be even smarter for the human important metadata (a string, probably) of recognizing the future event(s) be stored rather than a precise moment which may be incorrect.
- fallingknife 3y ago
  Locale and time are two separate pieces of data. Why store them together? Why not unix time and locale as two separate data points, and then mapping them to a human readable value is a UI concern?
  - mjevans 3y ago
    They are not, though it may be implicit in your thoughts that E.G. UTC or TAI or some other standard is associated with a single scalar value which represents some time along that frame of reference. However not all times are generated within such references. Most frequently (when sampling human facing outputs) times are printed within some other reference frame. As I tried to elaborate that usually relates to political realms, and there even cities may not be a sufficiently precise specification. (Offhand E.G. would timestamps from east and west Berlin while it was divided differ? I've not memorized that trivia, but it is one example of a politically divided city.) Further, not so many decades ago timezones along the western Americas coast happened to match, but have since diverged at times during the year due to political changes in timezone observations. It is not inconceivable that actions at a state, county, city, or other zoning level (E.G. Provences for Canada) might further change the meaning of a human friendly representation of an event (time in a place).
    - fallingknife 3y ago
      That makes sense, but really we are not going to be able to guarantee full accuracy of a timestamp against future changes in timezone boundaries. I guess if you had a GPS coordinate, that could be done, but it would be a monumental task for little benefit. Which is why IMO time data should be stored in unix, because then we can at least guarantee that we have an accurate ordering of events, at least within the precision of the timestamp. Would rather convert to unix at the time the event is recorded since we will be able to convert to the unix standard from whatever locale. If we store timestamps with a locale then we have to worry about the exact type of locale changes that you mentioned, and there is no guarantee that we will even know how to translate the locale that was stored at the time the TS was created. Sure, unix could change too (e.g. leap seconds), but I would be much more confident that time libraries will handle such changes
ogogmad 3y ago
> it's a simple integer that monotonically increases It isn't. See leap seconds. Using a string would allow you to distinguish UTC from UT1. Only UT1 is monotonic.
- jakobson14 3y ago
  I specifically did not say "UTC" at all. Read my actual comment. https://en.wikipedia.org/wiki/Unix_time https://en.wikipedia.org/wiki/Unix_time "Unix time is a date and time representation widely used in computing. It measures time by the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, the Unix epoch, without adjustments made due to leap seconds." Unix time does not include leap seconds or other adjustments.
  - ogogmad 3y ago
    scrubbed [Edit] From Wiki, your code is subtly mistaken: > When dealing with periods that do not encompass a UTC leap second, the difference between two Unix time numbers is equal to the duration in seconds of the period between the corresponding points in time. This is a common computational technique. However, where leap seconds occur, such calculations give the wrong answer. In applications where this level of accuracy is required, it is necessary to consult a table of leap seconds when dealing with Unix times, and it is often preferable to use a different time encoding that does not suffer from this problem.
    - jakobson14 3y ago
      That only matters if you care about taking leap seconds into account. If you want atomic clock time, not mushy political calendar time, then an integer number of ticks suffices. Would you prefer if I used the article's term of "precise time"? At any rate, it's a lot better to use precise time timestamps, as a single integer of seconds/miliseconds/vibrations of a caesium atom>, than a dumb "01/01/99" string of integers that rolls over and breaks at Y2K. (with associated fun parsing bugs)
      - 3y ago

mjevans 3y ago

Dates / timestamps fail to capture an 'event'. At best they are a partial event specification with the assumption that they are converted correctly to an assumed increment along a single time scale. Event specification is a very complex and politically entwined idea. This involves not just a frame of reference for the time, but also a location within which that time should make sense. Otherwise it is impossible to derive the correct rule-set for evaluating the human interpreted value of that moment. An alternative which might make sense is to force people to specify which ruleset they desire with the offset value within said ruleset. Sadly, my preferred representation of time isn't expressed in either of the popular standards (RFC 3339 or ISO-8601). https://ijmacd.github.io/rfc3339-iso8601/ https://ijmacd.github.io/rfc3339-iso8601/ RFC 3339 gets closet to my preference with: 2023-09-17 23:51:41Z However these are examples of what I'd prefer to see: * 2023-09-17 23:51:41 Z UTC * 2023-09-17 16:51:41 PST8PDT USA/WA/Seattle * 2023-09-17 16:51:41 PST8PDT Canada/British Columbia/Vancouver Note: At the moment Vancouver BC and Seattle WA happen to observe the same time offset but are in different political locales with different DST shift times. I'm not sure if it's still correct to call either timezone PST8PDT... that may imply the USA/CA/Los Angeles. Time would be expressed numerically 'large endian first' format, with zero or one punctuation element between units, preferably expressed with individual units matching the most correct (easiest for a human to read what they expect) value at a glance. This means - (or no separation) for dates, and : (or no separation) for HMS. (Space) or _ (Underscore) are preferable for between units. The timezone 'name' follows the smallest unit of time, which is itself followed by the reference city. Implicitly events in the past were accurate at the time they were encoded, while events in the future might need re-validation and conversion if the rules have changed. Though it would be even smarter for the human important metadata (a string, probably) of recognizing the future event(s) be stored rather than a precise moment which may be incorrect.

fallingknife 3y ago
Locale and time are two separate pieces of data. Why store them together? Why not unix time and locale as two separate data points, and then mapping them to a human readable value is a UI concern?
- mjevans 3y ago
  They are not, though it may be implicit in your thoughts that E.G. UTC or TAI or some other standard is associated with a single scalar value which represents some time along that frame of reference. However not all times are generated within such references. Most frequently (when sampling human facing outputs) times are printed within some other reference frame. As I tried to elaborate that usually relates to political realms, and there even cities may not be a sufficiently precise specification. (Offhand E.G. would timestamps from east and west Berlin while it was divided differ? I've not memorized that trivia, but it is one example of a politically divided city.) Further, not so many decades ago timezones along the western Americas coast happened to match, but have since diverged at times during the year due to political changes in timezone observations. It is not inconceivable that actions at a state, county, city, or other zoning level (E.G. Provences for Canada) might further change the meaning of a human friendly representation of an event (time in a place).
  - fallingknife 3y ago
    That makes sense, but really we are not going to be able to guarantee full accuracy of a timestamp against future changes in timezone boundaries. I guess if you had a GPS coordinate, that could be done, but it would be a monumental task for little benefit. Which is why IMO time data should be stored in unix, because then we can at least guarantee that we have an accurate ordering of events, at least within the precision of the timestamp. Would rather convert to unix at the time the event is recorded since we will be able to convert to the unix standard from whatever locale. If we store timestamps with a locale then we have to worry about the exact type of locale changes that you mentioned, and there is no guarantee that we will even know how to translate the locale that was stored at the time the TS was created. Sure, unix could change too (e.g. leap seconds), but I would be much more confident that time libraries will handle such changes

ogogmad 3y ago

> it's a simple integer that monotonically increases It isn't. See leap seconds. Using a string would allow you to distinguish UTC from UT1. Only UT1 is monotonic.

jakobson14 3y ago
I specifically did not say "UTC" at all. Read my actual comment. https://en.wikipedia.org/wiki/Unix_time https://en.wikipedia.org/wiki/Unix_time "Unix time is a date and time representation widely used in computing. It measures time by the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, the Unix epoch, without adjustments made due to leap seconds." Unix time does not include leap seconds or other adjustments.
- ogogmad 3y ago
  scrubbed [Edit] From Wiki, your code is subtly mistaken: > When dealing with periods that do not encompass a UTC leap second, the difference between two Unix time numbers is equal to the duration in seconds of the period between the corresponding points in time. This is a common computational technique. However, where leap seconds occur, such calculations give the wrong answer. In applications where this level of accuracy is required, it is necessary to consult a table of leap seconds when dealing with Unix times, and it is often preferable to use a different time encoding that does not suffer from this problem.
  - jakobson14 3y ago
    That only matters if you care about taking leap seconds into account. If you want atomic clock time, not mushy political calendar time, then an integer number of ticks suffices. Would you prefer if I used the article's term of "precise time"? At any rate, it's a lot better to use precise time timestamps, as a single integer of seconds/miliseconds/vibrations of a caesium atom>, than a dumb "01/01/99" string of integers that rolls over and breaks at Y2K. (with associated fun parsing bugs)
    - 3y ago