Home liberachat/#haskell: Logs Calendar

Logs: liberachat/#haskell

←Prev  Next→ 1,802,693 events total
2025-11-11 18:50:38 <EvanR> you mean if you convert to UTC?
2025-11-11 18:50:42 <sm> no! atlantean calendar
2025-11-11 18:50:48 Googulator8 joins (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu)
2025-11-11 18:50:49 <tomsmeding> anyway you can see the opposite jump here https://ircbrowse.tomsmeding.com/day/lchaskell/2025/03/30?id=1517022#trid1517022
2025-11-11 18:51:00 <EvanR> we lost logs or we will lose logs
2025-11-11 18:51:08 <tomsmeding> well the logs are still there in the plain znc logs
2025-11-11 18:51:14 <tomsmeding> but the website drops them
2025-11-11 18:51:18 <EvanR> nice
2025-11-11 18:51:35 tomsmeding checks if they're in the database
2025-11-11 18:51:48 <haskellbridge> <Zemyla> I'm pretty sure it's impossible, then.
2025-11-11 18:51:52 <EvanR> how many haskell programmers does it take to get time and date right
2025-11-11 18:52:25 <tomsmeding> well this is a combination of 1. the original author of ircbrowse creating this hideous postgres setup
2025-11-11 18:52:31 <humasect> it will be evaluated when necessary
2025-11-11 18:52:36 <tomsmeding> and apparently assuming that the server is in UTC
2025-11-11 18:52:43 <tomsmeding> and 2. me not doing that
2025-11-11 18:55:25 × Zemyla quits (~Zemyla@72.178.108.235) (Quit: Client closed)
2025-11-11 18:56:19 <tomsmeding> ok so the logs are there in the znc log files but the import to postgres borks
2025-11-11 18:56:41 <tomsmeding> the issue is this: the import to postgres assigns IDs to the events, and those IDs are not necessarily stable when you do a clean re-import of everything
2025-11-11 18:56:55 <tomsmeding> and people might have bookmarks to specific events, which have the ID in the URL
2025-11-11 18:57:14 <tomsmeding> I have wanted to rewrite this system for years but I never had the motivation to
2025-11-11 18:57:33 <tomsmeding> Zemyla: so possible, but rather a nuisancve
2025-11-11 18:58:57 × lucabtz quits (~lucabtz@user/lucabtz) (Remote host closed the connection)
2025-11-11 18:59:50 <tomsmeding> another part of the problem is that on a system with system time with DST, znc logs are technically ambiguous since it just contains the HH:MM:SS time for every message
2025-11-11 19:00:26 <EvanR> it would need a multi-part migration which does something to make a translation table of old IDs, reimports, then fixes all the IDs
2025-11-11 19:00:27 <tomsmeding> so when you switch from summer time to winter time and the clock goes back an hour, you get times between 01:00 and 02:00 twice
2025-11-11 19:01:04 <tomsmeding> if there are enough messages you can spot the jump and it's not ambiguous, but if there's, say, only one message in that two-hour slot, it's ambiguous where it is
2025-11-11 19:01:11 <tomsmeding> EvanR: possibly
2025-11-11 19:01:36 <EvanR> if there's only 1 message during the ambiguous period, may it's not that important what time it happened xD
2025-11-11 19:01:40 <EvanR> flip a coin
2025-11-11 19:01:45 <tomsmeding> that's a point
2025-11-11 19:02:06 <haskellbridge> <Zemyla> Yeah, you just have to make sure the overlap isn't a problem.
2025-11-11 19:02:36 <haskellbridge> <Zemyla> Very few people will care whether a message took place in the summer 1:30 or the winter 1:30.
2025-11-11 19:02:37 tromp joins (~textual@2001:1c00:3487:1b00:bd50:5f58:be67:a48d)
2025-11-11 19:03:26 <tomsmeding> it's whether it happened at 01:30 or 02:30 UTC
2025-11-11 19:04:44 <tomsmeding> you know what? I'm going to think about this later and you guys will have to live with the current mess a while longer :p
2025-11-11 19:05:23 <EvanR> the fascinating problems we put ourselves in
2025-11-11 19:06:49 haltingsolver joins (~cmo@2604:3d09:207f:8000:d250:ea0c:366a:6e73)
2025-11-11 19:07:15 <tomsmeding> DST should be abolished
2025-11-11 19:08:10 <tomsmeding> without DST I could just leave everything as-is and translate on-the-fly when serving the web page
2025-11-11 19:08:55 <tomsmeding> in a way it's weird in the first place that ircbrowse has the notion of "day", and that day is whatever matches the system timezone on the server it runs on
2025-11-11 19:09:48 <tomsmeding> for me, being in UTC+1/UTC+2, the UTC day would match closely enough with my calendar day that it's intuitive, but if you're, say, in California or in New Zealand, the ircbrowse "day" is something completely weird
2025-11-11 19:10:59 <tomsmeding> does anyone here remember what the old ircbrowse, when it was still hosted by its original creator (Chris Done), used as the timezone for events?
2025-11-11 19:11:13 <EvanR> yeah day (unless you're talking NASA MJD stuff) is really a localization thing
2025-11-11 19:13:23 <tomsmeding> EvanR: is this the authoritative reference on what the MJD is? https://core2.gsfc.nasa.gov/time/ Because it defines it as intrinsically linked to a _calendar_ day, with no timezone specified
2025-11-11 19:14:00 <EvanR> wow nice css
2025-11-11 19:14:16 <tomsmeding> "Last modified 17/3/00"
2025-11-11 19:15:35 <EvanR> since MJD is a specific number that I've seen in relation to interplanetary objects I presume it's defined specifically enough to get within the day, otherwise what's the point of the decimals
2025-11-11 19:15:49 Googulator7 joins (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu)
2025-11-11 19:15:57 <EvanR> now I'm going down a rabbit hole
2025-11-11 19:16:28 × dlock23 quits (~dlock@user/dlock23) (Quit: Leaving)
2025-11-11 19:18:07 × Googulator8 quits (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed)
2025-11-11 19:18:19 <tomsmeding> ok so this table https://en.wikipedia.org/wiki/Julian_day#Variants seems to interpret it as relative to UTC
2025-11-11 19:18:25 <tomsmeding> (I just refreshed it)
2025-11-11 19:18:59 <tomsmeding> > (floor (0.80278 * 24), floor ((0.80278 * 24 - 19) * 60))
2025-11-11 19:19:01 <lambdabot> (19,16)
2025-11-11 19:19:04 <EvanR> wikipedia page has references to noon = noon in UT
2025-11-11 19:19:18 <tomsmeding> oh right
2025-11-11 19:19:33 <tomsmeding> ok good, so it makes sense
2025-11-11 19:27:30 <monochrom> Oh, time leaps in IRC logs? They are awesome, please don't kill them! >:)
2025-11-11 19:27:31 <EvanR> (where UT is not exactly equal to UTC but close)
2025-11-11 19:28:04 <tomsmeding> monochrom: are they? :P
2025-11-11 19:28:55 <monochrom> We need to confuse future archaelogists by leaving around records that can be misinterpreted as evidence for we having figured out time travel!
2025-11-11 19:29:29 × humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Quit: Leaving...)
2025-11-11 19:29:33 fp joins (~Thunderbi@89-27-10-140.bb.dnainternet.fi)
2025-11-11 19:30:10 <tomsmeding> I don't think this is a particularly convincing exhibit to that end :p
2025-11-11 19:31:04 <monochrom> OK OK, s/archaeologists/ufologists/ ! >:D
2025-11-11 19:31:50 machinedgod joins (~machinedg@d75-159-126-101.abhsia.telus.net)
2025-11-11 19:37:25 × trickard_ quits (~trickard@cpe-62-98-47-163.wireline.com.au) (Ping timeout: 240 seconds)
2025-11-11 19:37:49 trickard_ joins (~trickard@cpe-62-98-47-163.wireline.com.au)
2025-11-11 19:40:11 <gentauro> EvanR: define "get time and date right" ;)
2025-11-11 19:40:17 <gentauro> it's actually not trivial
2025-11-11 19:40:41 <sm> he knwos
2025-11-11 19:40:46 <tomsmeding> so, many, apparently
2025-11-11 19:41:00 <gentauro> sm: everybody does ;)
2025-11-11 19:47:17 <gentauro> follow-up question, how many bits do you need to store `date` and `time` right? I vote for 96-bits (32 bits for date and 64 for time)
2025-11-11 19:49:00 humasect joins (~humasect@dyn-192-249-132-90.nexicom.net)
2025-11-11 19:56:21 <haskellbridge> <sm> that must be a trick question. The only right answer is to not answer :)
2025-11-11 19:57:10 <monochrom> haha
2025-11-11 19:57:24 × euphores quits (~SASL_euph@user/euphores) (Quit: Leaving.)
2025-11-11 19:59:56 × ThePenguin quits (~ThePengui@cust-95-80-28-221.csbnet.se) (Remote host closed the connection)
2025-11-11 20:00:41 × Digit quits (~user@user/digit) (Ping timeout: 244 seconds)
2025-11-11 20:02:00 ThePenguin joins (~ThePengui@cust-95-80-28-221.csbnet.se)
2025-11-11 20:07:45 <darkling> Number of Planck times since the Big Bang. :)
2025-11-11 20:08:47 <darkling> Signed integer, of course. Just in case.
2025-11-11 20:09:23 <tomsmeding> so how many bits? :P
2025-11-11 20:10:17 peterbecich joins (~Thunderbi@172.222.148.214)
2025-11-11 20:12:23 <darkling> Wikipedia says the Universe is about 8*10^60 Planck units old right now, so that's about 204 bits for present use.
2025-11-11 20:13:06 <monochrom> I was hoping that 128 would b enough.
2025-11-11 20:13:21 <monochrom> It's OK! We can go 512. :)
2025-11-11 20:13:34 <darkling> Max number of bits would depend on your favourite theory on the fate of the universe.
2025-11-11 20:14:08 <monochrom> Oh I just need a theory on the fate of this civilization.
2025-11-11 20:14:29 darkling checks watch
2025-11-11 20:14:34 <darkling> About 25 minutes?
2025-11-11 20:15:06 <monochrom> You are so generous :)
2025-11-11 20:15:12 <tomsmeding> monochrom: if you use planck time you already lose about 146 bits just describing one second
2025-11-11 20:16:17 <tomsmeding> ok 144, more precisely
2025-11-11 20:18:26 <haskellbridge> <Zemyla> In 10^200 years, all protons and neutrons in the universe will have likely decayed. Unless you plan on porting your data to diffuse electron-positron-photon clouds, I wouldn't worry about it.
2025-11-11 20:18:39 × annamalai quits (~annamalai@157.33.215.38) (Ping timeout: 256 seconds)
2025-11-11 20:20:30 × jreicher quits (~user@user/jreicher) (Quit: In transit)
2025-11-11 20:20:36 × Googulator7 quits (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed)

All times are in UTC.