Newest at the top
| 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 |
| 2025-05-06 14:53:59 +0200 | ttybitnik | (~ttybitnik@user/wolper) ttybitnik |
| 2025-05-06 14:51:36 +0200 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-05-06 14:37:42 +0200 | euleritian | (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) |
| 2025-05-06 14:37:07 +0200 | euleritian | (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2025-05-06 14:30:16 +0200 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:70a8:360f:569f:e3f9) ubert |
| 2025-05-06 14:29:39 +0200 | Square2 | (~Square4@user/square) (Ping timeout: 260 seconds) |
| 2025-05-06 14:28:10 +0200 | jespada | (~jespada@r179-25-149-142.dialup.adsl.anteldata.net.uy) jespada |
| 2025-05-06 14:24:45 +0200 | acidjnk | (~acidjnk@p200300d6e71c4f530114fa8f2e8a4c12.dip0.t-ipconnect.de) acidjnk |
| 2025-05-06 14:21:42 +0200 | euleritian | (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) |