12 ms·

Yeah this doesn't hold water. If you need the precision, float isn't suitable since he precision drops of. If you don't need the precision, no need to use float

Yeah this doesn't hold water. If you need the precision, float isn't suitable since he precision drops of. If you don't need the precision, no need to use float. Just use int64.

dragontamer 3y ago
> int64 I'll go one step further. Time should be represented as unsigned integers, while time-differences should be represented as signed integers. "10 minutes ago" is int64. June 9th 2023 should be unsigned integer64.
- dontlaugh 3y ago
  That doesn’t work, since it can’t represent dates before the epoch.
  - Kilenaitor 3y ago
    Wait if you just need dates, why not store dates? I was under impression unixtime is best for timestamps. But no reason to store something like a birthday using them; just do a string YYYY-MM-DD?
    - WalterBright 3y ago
      Because of daylight savings time and time zones.
      - dragontamer 3y ago
        Postgres's time handling types are elaborate, and probably the best I've personally worked with. Timestamp with TimeZone (including DST + timezone offset) is a different type from timestamp without TimeZone (ie: normalized to GMT). Timestamp - Timestamp results in "interval". Perhaps my method I was discussing doesn't work. But the overall idea that "Timestamp" needs to be a different type than "Interval", is pretty key IMO to handling date/times appropriately.
        hfkwer 3y ago
        Same in C#. DateTime, DateTimeOffset, TimeSpan.
        WalterBright 3y ago
        Everybody has this painful urge to reinvent the trivial in an incompatible way.
        WalterBright 3y ago
        > is pretty key IMO to A time_t can handle intervals just fine. time_t interval = t1 - t0;
        dragontamer 3y ago
        time_t will not handle daylight savings time conversions like Postgresql does. Unambiguously resolving "Timestamp at Eastern Time - Timestamp at Arizona Time" is not as simple as you might think. Postgresql handles this case. Trying to make "time_t" handle all cases is a mistake. We need like 3 to 4 types at a minimum to handle all of the edge cases that occur in the real world. (And if anyone teaches me of any more complications, maybe we'll need even more types)
        WalterBright 3y ago
        The idea is to store all times as time_t in UCT, and do all time calculations in UTC. Do conversions to/from local time only as a first and last step. It's the only sane way to do it. The D runtime library does that, and it has proven to be robust and sane. We're also recommending that users do the same thing with different character representations - do all calculation and processing in UTF-8. Other sets are translated upon input into UTF-8, and the UTF-8 is translated to other character sets only on output.
        dragontamer 3y ago
        > Do conversions to/from local time only as a first and last step. Cool. Now how do you enforce that? Spoiler: have the local-time be reported as a TimestampWithTimeZone. When you're doing calculations, make them all Timestamps. When you're done, you can remember that you've converted from internal UTC-timestamps into the proper output format because you'll have a TimestampWithTimezone again. ----------- We're programmers. We have problems that are simple and enforceable through compiler constructs called "The Type System". Why have the human figure out if they have time-zone back-and-forth correctly or otherwise made a mistake (ex: adding code to the wrong "part of the process" and accidentally mucking with a TimestampWithTimeZone input/output variable rather than the internal Timestamp-UTC-only type variables?) Just... leave the job of checking this entire process to the compiler. If your n00b coworker messes up, the type system catches it and we're all set.
    - dheera 3y ago
      For lots of use cases you want to record precise events in a universal sense, and be able to add and subtract them or compare whether one timestamp is the same exact time as another timestamp regardless of timezones. UNIX timestamps have no timezones. They are just the number of actual seconds that have elapsed since a certain commonly-agreed time. You measure the number of seconds between two events just by subtracting their timestamps arithmetically, and don't need to do any parsing or interpreting of timezones. You can just say "this hacker in Russia breached the firewall 35 seconds after this dev committed code in the US" just by subtracting two numbers. The time an airplane takes off, the time your firewall detected a security event, the time a cross-timezone meeting starts, these are all good to store as UNIX timestamps. Birthdays are different because they are inherently imprecise; humans tend to celebrate their birthdays when it's a certain day of the month in their local time zone, with little to no regard for the time zone they were born in. Someone born in Singapore (UTC+8) and lives in Alaska (UTC-8) might still celebrate their 30th birthday on the month and day of their birthday in Alaska time even though their body might need another 16 hours before it has technically experienced 30 years of life.
      - zokier 3y ago
        > UNIX timestamps have no timezones. They are just the number of actual seconds that have elapsed since a certain commonly-agreed time. You measure the number of seconds between two events just by subtracting their timestamps arithmetically, and don't need to do any parsing or interpreting of timezones If only. UNIX mishandling of leap seconds makes this all a illusion, in reality you need to have logic to handle them
        JohnFen 3y ago
        I don't think that UNIX mishandles leap seconds. It properly ignores them because they aren't relevant to it. The UNIX timestamp is literally the count of units past the epoch. The existence of leap seconds don't affect that count, it only affects the timekeeping of a completely different scheme. So yes, you have to handle leap seconds when you're converting from the timestamp to/from the time scheme you are interested in, just as you have to handle leap years, etc. The UNIX timestamp is just a different way of marking time, and is blessed with not worrying at all about how that time relates to the actual motion of the Earth. That makes it easy and consistent for common operations. It is not mishandling anything. It just can't shield you from the complexity of the forms of timekeeping that make it a point to be synchronized with the Earth.
    - dontlaugh 3y ago
      That’s not the point. How do you store a moment before 1970 if your timestamp is an unsigned integer?
      - Kilenaitor 3y ago
        This might seem like a silly question but could you give me an example use-case? I'm struggling to think of a context where we basically want to create timestamps for things that happened in the past. Especially things that we want to dynamically localize rather than e.g. just store as a straight up timestamped string.
        syntheweave 3y ago
        If you are creating a relationship between times in the past, you have to convert from string to something else. And the something else is always subject to some other detail - the calendar of the past is not defined identically throughout history, so you can't just extrapolate year-month-day backwards to get a time. Nobody's really solved this, it has to be tackled anew for each case of "comparing dates from long ago".
      - cdumler 3y ago
        With a p-adic number.
    - NoMoreNicksLeft 3y ago
      One might want to store legislation as a git repo. But to do that, you'd need pre-1970 timestamps. Git doesn't use string dates.
- duskwuff 3y ago
  > Time should be represented as unsigned integers Why artificially limit yourself to only representing times after the epoch? It's not like an extra bit of range is going to make or break anything.
  - uoaei 3y ago
    Adding one extra bit doubles the time horizon...
    - zamadatix 3y ago
      Sure but 1970 (or 1899 or 1582 or whatever) is a hell of a lot closer than 2^63 or what have you so why double the end already ridiculously far away instead of the one extremely close?
      - uoaei 3y ago
        i32 is used for Unix time, resulting in overflow sometime in 2038. If that was changed to u32, overflow would happen instead in 2106. 15 years is close enough that such a change would actually "make or break" timekeeping on human timescales. Using i64 for nanoseconds with the same origin (1970-01-01), we could cover roughly 1677-2262. Using u64 for nanoseconds we could cover roughly 1970-2554, or more generally about 585 years of timestamps from wherever a new proposed origin would be. Likely we don't need nanoscale precision for times far enough in the past, so I guess "far enough" is the definition worth arguing over here.
        zamadatix 3y ago
        You're looking far out for 2106 while ignoring the signing change already broke all date calculation from prior to the epoch. This means, with an unsigned version, you start out immediately butted against the problem that many real dates are not representable instead of running into this problem many years away. The advantage that future dates will be representable twice as far out doesn't make up for being butted up against the same problem in the other direction from the start. The same story is present with 64 bit nanosecond based timestamps, albeit we're keeping the mid date ever so slightly in the past for ease of conversion. If dates in 2264+ are important then just use a 128 bit timestamp, it'll fix the problem for many multiples the age of the universe instead of causing issues now to gain a few hundred years of padding in the future. Another common approach is to keep u64 second based timestamps and save the nanoseconds as another integer. This comes at the cost of "only" solving the problem for hundreds of billions of years but being interchangeable with those using non-fractional timestamps.
- Tuna-Fish 3y ago
  No, because times before 1970 exist. With signed timestamps, you have to figure out weird ways to represent when you need to talk about times in the past, with signed 64-bit timestamps you can represent any moment since well before big bang.
  - booi 3y ago
    > times before 1970 exist mmm I don’t think that’s true. - your computer
    - deleted 3y ago
      [deleted]
- layer8 3y ago
  If you use signed int64 to represent differences, then in order to be able to represent all possible differences, timestamps need to be restricted to a 63-bit range. Might as well use a signed int64 restricted to nonnegative numbers as an uint63, or restricted to 62 bits of each negative and nonnegative numbers as an int63. Alternatively, you’d need an int65.
- NoMoreNicksLeft 3y ago
  There are reasons to want pre-1070 dates. I need signed.
- lelanthran 3y ago
  > Time should be represented as unsigned integers, while time-differences should be represented as signed integers. > "10 minutes ago" is int64. June 9th 2023 should be unsigned integer64. Won't you run into problems with trying to turn "ten minutes before 1970" into a time? IOW, if you subtract two `time` types, the result must be a valid `time` type, so you can add/subtract to it. The result cannot be a `timediff` type.
  - feoren 3y ago
    > if you subtract two `time` types, the result must be a valid `time` type, so you can add/subtract to it. The result cannot be a `timediff` type. Huh? Of course `time` - `time` gives a `timediff` type. You can add/subtract to it: you add/subtract timediffs, or you can add/subtract a timediff to/from a time. Why would you ever be directly adding times? What is 100 AD + 100 AD? 200 AD? Not if you pick a different 0-point for your calendar ...
Gibbon1 3y ago
As an aside dang would probably ban my account if I let rip about what I think about hardware engineers designing real time clocks that count time in HH:MM:SS + day/month/two digit year. And 100 or 128 hz subseconds. But yeah started using int64 30 years ago and all the fuckedness went away.
- marcosdumay 3y ago
  Yeah, with 64 bits we can go into 1/32768 of second precision and still not get any problem.
- fredoralive 3y ago
  I suspect the hardware engineer would explain the great favour he’s doing you by handling all the handling of all the weird splits between things like hours, minutes and days for you in hardware logic, rather than you having to waste previous cycles of your MCU’s core to do that sort of thing. But it is indeed a real pain when you want dates in more abstract than human forms…
  - JohnFen 3y ago
    Yeah, that hardware engineer isn't really doing anyone any favors.
  - JdeBP 3y ago
    The rest of us, including a number of hardware engineers who have learned from history, would point to the real-time clock chip that did hardware rules for things right for only one country for a mere three years in the 1980s, until the legislation changed, and whose behaviour has been wrong ever since. Step forward the MC146818, used in the PC/AT and emulated by chipsets since, whose built-in daylight savings time change rule implemented in hardware was rendered obsolete in 1987. http://catless.ncl.ac.uk./Risks/24.60.html#subj12.1 http://catless.ncl.ac.uk./Risks/24.60.html#subj12.1
    - Gibbon1 3y ago
      Old electrical engineer I worked under in the 1980's mentioned he designed a clock calendar STD Bus card. Next design he replaced the whole thing with a 32 bit counter on the processor card and 250 bytes of Z80 assembly. Unrelated I think the lobbyists that got daylight savings time changed charged the BBQ manufacturers $50k.

Yeah this doesn't hold water. If you need the precision, float isn't suitable since he precision drops of. If you don't need the precision, no need to use float. Just use int64.

dragontamer 3y ago

> int64 I'll go one step further. Time should be represented as unsigned integers, while time-differences should be represented as signed integers. "10 minutes ago" is int64. June 9th 2023 should be unsigned integer64.

dontlaugh 3y ago
That doesn’t work, since it can’t represent dates before the epoch.
- Kilenaitor 3y ago
  Wait if you just need dates, why not store dates? I was under impression unixtime is best for timestamps. But no reason to store something like a birthday using them; just do a string YYYY-MM-DD?
  - WalterBright 3y ago
    Because of daylight savings time and time zones.
    - dragontamer 3y ago
      Postgres's time handling types are elaborate, and probably the best I've personally worked with. Timestamp with TimeZone (including DST + timezone offset) is a different type from timestamp without TimeZone (ie: normalized to GMT). Timestamp - Timestamp results in "interval". Perhaps my method I was discussing doesn't work. But the overall idea that "Timestamp" needs to be a different type than "Interval", is pretty key IMO to handling date/times appropriately.
      - hfkwer 3y ago
        Same in C#. DateTime, DateTimeOffset, TimeSpan.
        WalterBright 3y ago
        Everybody has this painful urge to reinvent the trivial in an incompatible way.
      - WalterBright 3y ago
        > is pretty key IMO to A time_t can handle intervals just fine. time_t interval = t1 - t0;
        dragontamer 3y ago
        time_t will not handle daylight savings time conversions like Postgresql does. Unambiguously resolving "Timestamp at Eastern Time - Timestamp at Arizona Time" is not as simple as you might think. Postgresql handles this case. Trying to make "time_t" handle all cases is a mistake. We need like 3 to 4 types at a minimum to handle all of the edge cases that occur in the real world. (And if anyone teaches me of any more complications, maybe we'll need even more types)
        WalterBright 3y ago
        The idea is to store all times as time_t in UCT, and do all time calculations in UTC. Do conversions to/from local time only as a first and last step. It's the only sane way to do it. The D runtime library does that, and it has proven to be robust and sane. We're also recommending that users do the same thing with different character representations - do all calculation and processing in UTF-8. Other sets are translated upon input into UTF-8, and the UTF-8 is translated to other character sets only on output.
        dragontamer 3y ago
        > Do conversions to/from local time only as a first and last step. Cool. Now how do you enforce that? Spoiler: have the local-time be reported as a TimestampWithTimeZone. When you're doing calculations, make them all Timestamps. When you're done, you can remember that you've converted from internal UTC-timestamps into the proper output format because you'll have a TimestampWithTimezone again. ----------- We're programmers. We have problems that are simple and enforceable through compiler constructs called "The Type System". Why have the human figure out if they have time-zone back-and-forth correctly or otherwise made a mistake (ex: adding code to the wrong "part of the process" and accidentally mucking with a TimestampWithTimeZone input/output variable rather than the internal Timestamp-UTC-only type variables?) Just... leave the job of checking this entire process to the compiler. If your n00b coworker messes up, the type system catches it and we're all set.
  - dheera 3y ago
    For lots of use cases you want to record precise events in a universal sense, and be able to add and subtract them or compare whether one timestamp is the same exact time as another timestamp regardless of timezones. UNIX timestamps have no timezones. They are just the number of actual seconds that have elapsed since a certain commonly-agreed time. You measure the number of seconds between two events just by subtracting their timestamps arithmetically, and don't need to do any parsing or interpreting of timezones. You can just say "this hacker in Russia breached the firewall 35 seconds after this dev committed code in the US" just by subtracting two numbers. The time an airplane takes off, the time your firewall detected a security event, the time a cross-timezone meeting starts, these are all good to store as UNIX timestamps. Birthdays are different because they are inherently imprecise; humans tend to celebrate their birthdays when it's a certain day of the month in their local time zone, with little to no regard for the time zone they were born in. Someone born in Singapore (UTC+8) and lives in Alaska (UTC-8) might still celebrate their 30th birthday on the month and day of their birthday in Alaska time even though their body might need another 16 hours before it has technically experienced 30 years of life.
    - zokier 3y ago
      > UNIX timestamps have no timezones. They are just the number of actual seconds that have elapsed since a certain commonly-agreed time. You measure the number of seconds between two events just by subtracting their timestamps arithmetically, and don't need to do any parsing or interpreting of timezones If only. UNIX mishandling of leap seconds makes this all a illusion, in reality you need to have logic to handle them
      - JohnFen 3y ago
        I don't think that UNIX mishandles leap seconds. It properly ignores them because they aren't relevant to it. The UNIX timestamp is literally the count of units past the epoch. The existence of leap seconds don't affect that count, it only affects the timekeeping of a completely different scheme. So yes, you have to handle leap seconds when you're converting from the timestamp to/from the time scheme you are interested in, just as you have to handle leap years, etc. The UNIX timestamp is just a different way of marking time, and is blessed with not worrying at all about how that time relates to the actual motion of the Earth. That makes it easy and consistent for common operations. It is not mishandling anything. It just can't shield you from the complexity of the forms of timekeeping that make it a point to be synchronized with the Earth.
  - dontlaugh 3y ago
    That’s not the point. How do you store a moment before 1970 if your timestamp is an unsigned integer?
    - Kilenaitor 3y ago
      This might seem like a silly question but could you give me an example use-case? I'm struggling to think of a context where we basically want to create timestamps for things that happened in the past. Especially things that we want to dynamically localize rather than e.g. just store as a straight up timestamped string.
      - syntheweave 3y ago
        If you are creating a relationship between times in the past, you have to convert from string to something else. And the something else is always subject to some other detail - the calendar of the past is not defined identically throughout history, so you can't just extrapolate year-month-day backwards to get a time. Nobody's really solved this, it has to be tackled anew for each case of "comparing dates from long ago".
    - cdumler 3y ago
      With a p-adic number.
  - NoMoreNicksLeft 3y ago
    One might want to store legislation as a git repo. But to do that, you'd need pre-1970 timestamps. Git doesn't use string dates.
duskwuff 3y ago
> Time should be represented as unsigned integers Why artificially limit yourself to only representing times after the epoch? It's not like an extra bit of range is going to make or break anything.
- uoaei 3y ago
  Adding one extra bit doubles the time horizon...
  - zamadatix 3y ago
    Sure but 1970 (or 1899 or 1582 or whatever) is a hell of a lot closer than 2^63 or what have you so why double the end already ridiculously far away instead of the one extremely close?
    - uoaei 3y ago
      i32 is used for Unix time, resulting in overflow sometime in 2038. If that was changed to u32, overflow would happen instead in 2106. 15 years is close enough that such a change would actually "make or break" timekeeping on human timescales. Using i64 for nanoseconds with the same origin (1970-01-01), we could cover roughly 1677-2262. Using u64 for nanoseconds we could cover roughly 1970-2554, or more generally about 585 years of timestamps from wherever a new proposed origin would be. Likely we don't need nanoscale precision for times far enough in the past, so I guess "far enough" is the definition worth arguing over here.
      - zamadatix 3y ago
        You're looking far out for 2106 while ignoring the signing change already broke all date calculation from prior to the epoch. This means, with an unsigned version, you start out immediately butted against the problem that many real dates are not representable instead of running into this problem many years away. The advantage that future dates will be representable twice as far out doesn't make up for being butted up against the same problem in the other direction from the start. The same story is present with 64 bit nanosecond based timestamps, albeit we're keeping the mid date ever so slightly in the past for ease of conversion. If dates in 2264+ are important then just use a 128 bit timestamp, it'll fix the problem for many multiples the age of the universe instead of causing issues now to gain a few hundred years of padding in the future. Another common approach is to keep u64 second based timestamps and save the nanoseconds as another integer. This comes at the cost of "only" solving the problem for hundreds of billions of years but being interchangeable with those using non-fractional timestamps.
Tuna-Fish 3y ago
No, because times before 1970 exist. With signed timestamps, you have to figure out weird ways to represent when you need to talk about times in the past, with signed 64-bit timestamps you can represent any moment since well before big bang.
- booi 3y ago
  > times before 1970 exist mmm I don’t think that’s true. - your computer
  - deleted 3y ago
    [deleted]
layer8 3y ago
If you use signed int64 to represent differences, then in order to be able to represent all possible differences, timestamps need to be restricted to a 63-bit range. Might as well use a signed int64 restricted to nonnegative numbers as an uint63, or restricted to 62 bits of each negative and nonnegative numbers as an int63. Alternatively, you’d need an int65.
NoMoreNicksLeft 3y ago
There are reasons to want pre-1070 dates. I need signed.
lelanthran 3y ago
> Time should be represented as unsigned integers, while time-differences should be represented as signed integers. > "10 minutes ago" is int64. June 9th 2023 should be unsigned integer64. Won't you run into problems with trying to turn "ten minutes before 1970" into a time? IOW, if you subtract two `time` types, the result must be a valid `time` type, so you can add/subtract to it. The result cannot be a `timediff` type.
- feoren 3y ago
  > if you subtract two `time` types, the result must be a valid `time` type, so you can add/subtract to it. The result cannot be a `timediff` type. Huh? Of course `time` - `time` gives a `timediff` type. You can add/subtract to it: you add/subtract timediffs, or you can add/subtract a timediff to/from a time. Why would you ever be directly adding times? What is 100 AD + 100 AD? 200 AD? Not if you pick a different 0-point for your calendar ...

Gibbon1 3y ago

As an aside dang would probably ban my account if I let rip about what I think about hardware engineers designing real time clocks that count time in HH:MM:SS + day/month/two digit year. And 100 or 128 hz subseconds. But yeah started using int64 30 years ago and all the fuckedness went away.

marcosdumay 3y ago
Yeah, with 64 bits we can go into 1/32768 of second precision and still not get any problem.
fredoralive 3y ago
I suspect the hardware engineer would explain the great favour he’s doing you by handling all the handling of all the weird splits between things like hours, minutes and days for you in hardware logic, rather than you having to waste previous cycles of your MCU’s core to do that sort of thing. But it is indeed a real pain when you want dates in more abstract than human forms…
- JohnFen 3y ago
  Yeah, that hardware engineer isn't really doing anyone any favors.
- JdeBP 3y ago
  The rest of us, including a number of hardware engineers who have learned from history, would point to the real-time clock chip that did hardware rules for things right for only one country for a mere three years in the 1980s, until the legislation changed, and whose behaviour has been wrong ever since. Step forward the MC146818, used in the PC/AT and emulated by chipsets since, whose built-in daylight savings time change rule implemented in hardware was rendered obsolete in 1987. http://catless.ncl.ac.uk./Risks/24.60.html#subj12.1 http://catless.ncl.ac.uk./Risks/24.60.html#subj12.1
  - Gibbon1 3y ago
    Old electrical engineer I worked under in the 1980's mentioned he designed a clock calendar STD Bus card. Next design he replaced the whole thing with a 32 bit counter on the processor card and 250 bytes of Z80 assembly. Unrelated I think the lobbyists that got daylight savings time changed charged the BBQ manufacturers $50k.