Newest at the top
| 2025-05-06 15:38:52 +0200 | <tomsmeding> | s/something/does something/ |
| 2025-05-06 15:38:41 +0200 | <tomsmeding> | if you set the seconds field to some other value then you're inputting a non-existent UTC time, and utcTimeToPosixSeconds... something |
| 2025-05-06 15:38:27 +0200 | <yin> | exactly |
| 2025-05-06 15:38:18 +0200 | <yin> | lortabac: Posix time does not account for leap seconds |
| 2025-05-06 15:38:01 +0200 | <tomsmeding> | lortabac: POSIX does not count leap seconds, so as long as you only use the additional freedom in UTCTime to set the seconds field to 60 in case of a leap second, utcTimeToPosixSeconds is actually correct |
| 2025-05-06 15:37:41 +0200 | <yin> | hence my comments about how the permissive UTCTime implementation makes sense |
| 2025-05-06 15:37:13 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 265 seconds) |
| 2025-05-06 15:36:52 +0200 | <lortabac> | but then utcTimeToPosixSeconds is wrong |
| 2025-05-06 15:36:43 +0200 | <tomsmeding> | yin: fair correction, but does not change my conclusion |
| 2025-05-06 15:36:40 +0200 | <lortabac> | so in this sense UTCTime is right in not wrapping |
| 2025-05-06 15:36:29 +0200 | <tomsmeding> | https://en.wikipedia.org/wiki/Leap_second#Binary_representation |
| 2025-05-06 15:36:16 +0200 | <yin> | yes |
| 2025-05-06 15:36:04 +0200 | <tomsmeding> | yin: so what happens at a leap second, do you get :60 in the UTC time? |
| 2025-05-06 15:35:42 +0200 | <df> | tbh I'm not sure if posix has been updated to be 64 bit |
| 2025-05-06 15:35:35 +0200 | tomsmeding | should probably have looked things up |
| 2025-05-06 15:35:30 +0200 | <yin> | no 2 seconds have the same timestamp in UTC |
| 2025-05-06 15:35:19 +0200 | <yin> | tomsmeding: that's not true |
| 2025-05-06 15:35:03 +0200 | <tomsmeding> | POSIX timestamps match UTC |
| 2025-05-06 15:34:53 +0200 | <tomsmeding> | (after wrapping, perhaps) |
| 2025-05-06 15:34:43 +0200 | <tomsmeding> | whereas UTC actually intends to match what humans do, so when there's a leap second, you have two seconds with the same UTC time |
| 2025-05-06 15:34:24 +0200 | <tomsmeding> | iirc TAI just trudges on, regardless of what we pesky humans do with calendars and leap seconds |
| 2025-05-06 15:34:06 +0200 | <df> | but I've no idea which one posix timestamps are based on |
| 2025-05-06 15:33:43 +0200 | <df> | I thought it was TAI that didn't include leap seconds |
| 2025-05-06 15:33:32 +0200 | <tomsmeding> | that means that conversion between UTC time and a POSIX timestamp does not need to care about leap seconds |
| 2025-05-06 15:32:47 +0200 | <tomsmeding> | a posix timestamp does not include leap seconds, there, that does |
| 2025-05-06 15:32:42 +0200 | <tomsmeding> | that makes no sense |
| 2025-05-06 15:32:40 +0200 | <tomsmeding> | uh |
| 2025-05-06 15:32:33 +0200 | <tomsmeding> | lortabac: UTC does not include leap seconds |
| 2025-05-06 15:31:51 +0200 | <yin> | for the british empire |
| 2025-05-06 15:31:26 +0200 | <yin> | or 11 days in 1752 |
| 2025-05-06 15:31:25 +0200 | <lortabac> | :) |
| 2025-05-06 15:31:05 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-05-06 15:30:43 +0200 | <yin> | 100000 seconds is just about 11 days and a half. we've famously skipped 10 days in 1582 :) |
| 2025-05-06 15:30:25 +0200 | j1n37- | (~j1n37@user/j1n37) (Ping timeout: 276 seconds) |
| 2025-05-06 15:30:11 +0200 | <lortabac> | posixDayLength is hard-coded as 86400 seconds |
| 2025-05-06 15:29:25 +0200 | <lortabac> | I wonder if it handles leap seconds correctly |
| 2025-05-06 15:28:38 +0200 | <lortabac> | still, utcTimeToPOSIXSeconds seems to enforce a limit |
| 2025-05-06 15:28:21 +0200 | <lortabac> | yin: right, it makes sense |
| 2025-05-06 15:27:59 +0200 | <yin> | lortabac: *standard. meaning if the future it's possible for us to add an arbitrary number of seconds to a day. we routinely have leap seconds |
| 2025-05-06 15:27:04 +0200 | <lortabac> | if I do (posixSecondsToUTCTime $ utcTimeToPOSIXSeconds impossibleTime) it gives me the next day at 00:00:00 |
| 2025-05-06 15:26:54 +0200 | <yin> | lortabac: the UTC standart itself does not enforce it |
| 2025-05-06 15:23:50 +0200 | <tomsmeding> | but yeah, I agree that a smart constructor that implements wrapping behaviour would have been neater |
| 2025-05-06 15:23:24 +0200 | <tomsmeding> | 'time' itself seems to use utcTimeToPosixSeconds a lot |
| 2025-05-06 15:23:04 +0200 | <lortabac> | and how an impossible date would behave in various scenarios and conversions |
| 2025-05-06 15:22:34 +0200 | <lortabac> | I already have a solution for my specific problem. I'm mostly wondering whether this is a good API for time |
| 2025-05-06 15:21:14 +0200 | <tomsmeding> | if wrapping is the behaviour that you want |
| 2025-05-06 15:20:49 +0200 | <tomsmeding> | you could (n `addUTCTime` UTCTime date 0) |
| 2025-05-06 15:20:02 +0200 | AlexZenon | (~alzenon@5.139.233.9) |
| 2025-05-06 15:19:46 +0200 | <lortabac> | I don't know, it seems strange to me that you are allowed to create such a date |
| 2025-05-06 15:19:06 +0200 | <lortabac> | by providing a smart constructor |