Logs: liberachat/#haskell
| 2021-06-10 07:31:47 | → | zaquest joins (~notzaques@5.128.210.178) |
| 2021-06-10 07:32:14 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-06-10 07:33:26 | → | gehmehgeh joins (~user@user/gehmehgeh) |
| 2021-06-10 07:34:09 | → | kuribas joins (~user@ptr-25vy0i6v9tbds0gjkm6.18120a2.ip6.access.telenet.be) |
| 2021-06-10 07:35:24 | × | zaquest quits (~notzaques@5.128.210.178) (Client Quit) |
| 2021-06-10 07:35:38 | → | zaquest joins (~notzaques@5.128.210.178) |
| 2021-06-10 07:37:38 | → | fendor joins (~fendor@77.119.128.226.wireless.dyn.drei.com) |
| 2021-06-10 07:37:56 | → | oxide joins (~lambda@user/oxide) |
| 2021-06-10 07:39:48 | → | yoctocell joins (~yoctocell@h87-96-130-155.cust.a3fiber.se) |
| 2021-06-10 07:40:55 | × | betelgeuse quits (~john2gb@94-225-47-8.access.telenet.be) (Quit: The Lounge - https://thelounge.chat) |
| 2021-06-10 07:42:09 | × | oxide quits (~lambda@user/oxide) (Ping timeout: 245 seconds) |
| 2021-06-10 07:42:42 | → | benin03 joins (~benin@183.82.176.4) |
| 2021-06-10 07:42:44 | × | nsilv quits (~nsilv@212.103.198.210) (Ping timeout: 272 seconds) |
| 2021-06-10 07:44:47 | → | nsilv joins (~nsilv@212.103.198.210) |
| 2021-06-10 07:44:47 | × | mikoto-chan quits (~mikoto-ch@ip-213-49-189-31.dsl.scarlet.be) (Read error: Connection reset by peer) |
| 2021-06-10 07:45:09 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-06-10 07:45:25 | → | mikoto-chan joins (~mikoto-ch@ip-213-49-189-31.dsl.scarlet.be) |
| 2021-06-10 07:45:46 | → | td_ joins (~td@94.134.91.190) |
| 2021-06-10 07:46:10 | × | xkuru quits (~xkuru@user/xkuru) (Read error: Connection reset by peer) |
| 2021-06-10 07:52:21 | → | oxide joins (~lambda@user/oxide) |
| 2021-06-10 07:56:45 | × | econo quits (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2021-06-10 07:56:46 | → | fizbin joins (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) |
| 2021-06-10 08:00:54 | × | fizbin quits (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) (Ping timeout: 245 seconds) |
| 2021-06-10 08:02:04 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-06-10 08:03:11 | × | alex3 quits (~Chel@BSN-77-82-41.static.siol.net) (Quit: WeeChat 3.0) |
| 2021-06-10 08:07:27 | → | hendursa1 joins (~weechat@user/hendursaga) |
| 2021-06-10 08:07:43 | → | alex2 joins (~alex3@BSN-77-82-41.static.siol.net) |
| 2021-06-10 08:09:24 | × | alex2 quits (~alex3@BSN-77-82-41.static.siol.net) (Client Quit) |
| 2021-06-10 08:09:31 | → | alex2 joins (~alex3@BSN-77-82-41.static.siol.net) |
| 2021-06-10 08:10:12 | × | alex2 quits (~alex3@BSN-77-82-41.static.siol.net) (Client Quit) |
| 2021-06-10 08:10:18 | → | alex3 joins (~alex3@BSN-77-82-41.static.siol.net) |
| 2021-06-10 08:10:19 | × | hendursaga quits (~weechat@user/hendursaga) (Ping timeout: 252 seconds) |
| 2021-06-10 08:11:16 | → | pera joins (~pera@70.red-88-14-152.dynamicip.rima-tde.net) |
| 2021-06-10 08:11:39 | pera | is now known as Guest1402 |
| 2021-06-10 08:13:46 | × | Guest1402 quits (~pera@70.red-88-14-152.dynamicip.rima-tde.net) (Client Quit) |
| 2021-06-10 08:15:12 | × | oxide quits (~lambda@user/oxide) (Read error: Connection reset by peer) |
| 2021-06-10 08:18:04 | × | ubert quits (~Thunderbi@p200300ecdf259d4b4d0b89c625dcbc13.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2021-06-10 08:18:31 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-06-10 08:18:45 | × | tzh quits (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2021-06-10 08:19:00 | × | eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:2121:a570:d35e:ba7a) (Remote host closed the connection) |
| 2021-06-10 08:19:36 | → | eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:2121:a570:d35e:ba7a) |
| 2021-06-10 08:21:15 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-06-10 08:21:46 | × | yd502 quits (~yd502@180.168.212.6) (Ping timeout: 244 seconds) |
| 2021-06-10 08:22:12 | → | larkfisherman joins (~larkfishe@217.75.204.126) |
| 2021-06-10 08:22:15 | → | xkuru joins (~xkuru@user/xkuru) |
| 2021-06-10 08:23:50 | × | eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:2121:a570:d35e:ba7a) (Ping timeout: 244 seconds) |
| 2021-06-10 08:24:30 | → | qoelet joins (~kumo@139.180.144.166) |
| 2021-06-10 08:26:00 | × | jco quits (~jco@c83-248-173-38.bredband.tele2.se) (Remote host closed the connection) |
| 2021-06-10 08:30:23 | <dminuoso> | If my program is started by cron at 00:00:00, is it possible for getSystemTime to give me the timestamp at 23:59 from yesterday? |
| 2021-06-10 08:30:58 | <Taneb> | Probably, computer time is weird. |
| 2021-06-10 08:31:02 | <merijn> | Probably |
| 2021-06-10 08:31:16 | <merijn> | Negative leap second coming up Soon-ish (TM) :p |
| 2021-06-10 08:31:24 | <dminuoso> | Yeah, though negative leap second is fine with me. |
| 2021-06-10 08:31:25 | <merijn> | RIP our collective sanity |
| 2021-06-10 08:31:40 | <kritzefitz> | Definitely if the realtime clock is set in the meantime by NTP or something else. |
| 2021-06-10 08:31:59 | <dminuoso> | I guess ntp is a rather realistic scenario |
| 2021-06-10 08:33:01 | <c_wraith> | NTP shouldn't move the clock backwards - though tools like ntpdate will |
| 2021-06-10 08:33:04 | <dminuoso> | Maybe I should just do the obvious and start it at 00:01:00, that way funny leap seconds or small drift fixes by NTP wont harm me. |
| 2021-06-10 08:33:06 | → | peterhil joins (~peterhil@dsl-hkibng32-54f849-252.dhcp.inet.fi) |
| 2021-06-10 08:33:22 | <dminuoso> | c_wraith: It shouldn't? What if my clock runs too fast? Would it keep going into the future indefinitely? |
| 2021-06-10 08:33:46 | <c_wraith> | NTP is intended to keep the clock monotonic - it will slow it down if you're ahead, rather than moving it backwards |
| 2021-06-10 08:35:13 | <dminuoso> | I see. |
| 2021-06-10 08:35:15 | × | Erutuon quits (~Erutuon@user/erutuon) (Ping timeout: 252 seconds) |
| 2021-06-10 08:37:04 | <dminuoso> | How exactly does getSystemTime work anyway? How is time measured to this accuracy? Does the CPU calculate it from a clock cycle count and clock rate? |
| 2021-06-10 08:37:16 | <tdammers> | AFAIK, most ntp clients will "jump" when the error exceeds a certain margin |
| 2021-06-10 08:37:37 | <dminuoso> | (And how does all of this even work sensible on multi-core systems) |
| 2021-06-10 08:37:38 | <tdammers> | like, when you're six days ahead, just slowing down would mean it'd take weeks to catch up, so that's not a good option |
| 2021-06-10 08:38:12 | <Maxdamantus> | What system calls does it use to slow down time? |
| 2021-06-10 08:38:58 | urtie | is now known as earthy |
| 2021-06-10 08:40:17 | <Maxdamantus> | Ah, hm. Apparently that's what adjtime does. |
| 2021-06-10 08:41:32 | <dminuoso> | Ah I guess you'd just set up a timer interrupt, which preempts the CPU and then increases a counter. |
| 2021-06-10 08:41:47 | <dminuoso> | Can time be monotone in a multi-core environment? |
| 2021-06-10 08:42:18 | <dminuoso> | Oh this is giving too much headaches. Im going to pretend its monotone for the sake of sanity. |
| 2021-06-10 08:42:31 | <tdammers> | "eventual monotonicity" |
| 2021-06-10 08:42:32 | <Maxdamantus> | It can. I imagine it probably is. |
| 2021-06-10 08:42:50 | <kritzefitz> | dminuoso, at least on unix systems there are different clocks with different guarantees- |
| 2021-06-10 08:42:52 | <c_wraith> | it's pretty common to set cron tasks to happen just after midnight because you don't want to deal with this :) |
| 2021-06-10 08:43:08 | <kritzefitz> | One of those guarantees is monotonicity. |
| 2021-06-10 08:43:20 | <kritzefitz> | But getSystemTime doesn't use a clock with that guarantee. |
| 2021-06-10 08:43:27 | <dminuoso> | Maxdamantus: Yes? No? Maybe? Memory consistency is a thing. :p |
| 2021-06-10 08:43:39 | <merijn> | dminuoso: Just use a monotone clock for you timings? |
| 2021-06-10 08:43:50 | <merijn> | @hackage clock |
| 2021-06-10 08:43:50 | <lambdabot> | https://hackage.haskell.org/package/clock |
| 2021-06-10 08:43:58 | <merijn> | Don't use getSystemTime for this kinda thing |
| 2021-06-10 08:44:04 | <Maxdamantus> | dminuoso: as long as people take memory consistency into account, it should be possible. |
| 2021-06-10 08:44:30 | <dminuoso> | merijn: As for technical requirement, Im just bikeshedding a bit for the purpose of understanding. I just have a business requirement to work in terms of legal days. |
| 2021-06-10 08:44:54 | <Maxdamantus> | dminuoso: you can come up with a model where if one request for the time "happens after" another, it will get a greater (or equal) time. |
| 2021-06-10 08:45:04 | <merijn> | Is there even a definition of "legal day" |
| 2021-06-10 08:45:09 | <dminuoso> | no clue |
| 2021-06-10 08:45:16 | <merijn> | Well, that's step one, then |
| 2021-06-10 08:45:16 | <dminuoso> | Probably :) |
| 2021-06-10 08:45:24 | <merijn> | Everything else is pointless until you know what it is |
| 2021-06-10 08:46:58 | <dminuoso> | So the technical requirement is that I need to activate an account on its activation date precisely at midnight. A minute drift is acceptable to the customer. I was just wondering how reliable `utctDay . systemToUTCTime <$> liftIO getSystemTime` would be for the task to identify whether today is the proper activation date. |
| 2021-06-10 08:47:25 | <dminuoso> | Of course I can fix that with a heuristic that checks whether the current time is somewhere in the vicinity of midnight. If its shortly before, pretend its the next day, etc |
| 2021-06-10 08:48:05 | <dminuoso> | This topic then introduced a bunch of related and unrelated questions regarding how time works anyway |
| 2021-06-10 08:48:45 | <kritzefitz> | I think your best bet for a real time solution is to actually run a bit after midnight, so slight variations won't change the day. |
| 2021-06-10 08:48:53 | <kritzefitz> | s/real time/real worl/ |
| 2021-06-10 08:49:36 | <dminuoso> | kritzefitz: Dunno, running precisely at midnight, but adding say 5 minutes to the system time before taking the day seems like a better solution |
| 2021-06-10 08:50:06 | <dminuoso> | That way I get to run as close to midnight as possible, but allowing for slight variations still |
| 2021-06-10 08:50:24 | <kritzefitz> | So running close to midnight is important? |
All times are in UTC.