Newest at the top
| 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 |
| 2025-05-06 15:18:47 +0200 | <tomsmeding> | I mean, how can a data type enforce invariants |
| 2025-05-06 15:18:18 +0200 | <lortabac> | and then it shows it as 2025-05-06 23:59:913660 UTC |
| 2025-05-06 15:18:03 +0200 | <lortabac> | you can do for example (UTCTime date (secondsToDiffTime 1000000)) and it will gladly accept it |
| 2025-05-06 15:17:03 +0200 | <lortabac> | I've just discovered that UTCTime doesn't enforce any invariant on the number of seconds in a day |
| 2025-05-06 15:15:28 +0200 | AlexZenon | (~alzenon@5.139.233.9) (Ping timeout: 265 seconds) |
| 2025-05-06 15:13:29 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 268 seconds) |
| 2025-05-06 15:12:54 +0200 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-05-06 15:03:46 +0200 | <mauke> | yin: I had a prototype implementation for Perl, but they didn't like my suggested f($x)($y) calling syntax :-( |
| 2025-05-06 15:02:54 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
| 2025-05-06 15:00:17 +0200 | comerijn | (~merijn@77.242.116.146) merijn |
| 2025-05-06 14:56:38 +0200 | gorignak | (~gorignak@user/gorignak) gorignak |