Newest at the top
| 2025-11-11 20:47:17 +0100 | <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 20:41:00 +0100 | <gentauro> | sm: everybody does ;) |
| 2025-11-11 20:40:46 +0100 | <tomsmeding> | so, many, apparently |
| 2025-11-11 20:40:41 +0100 | <sm> | he knwos |
| 2025-11-11 20:40:17 +0100 | <gentauro> | it's actually not trivial |
| 2025-11-11 20:40:11 +0100 | <gentauro> | EvanR: define "get time and date right" ;) |
| 2025-11-11 20:37:49 +0100 | trickard_ | (~trickard@cpe-62-98-47-163.wireline.com.au) |
| 2025-11-11 20:37:25 +0100 | trickard_ | (~trickard@cpe-62-98-47-163.wireline.com.au) (Ping timeout: 240 seconds) |
| 2025-11-11 20:31:50 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod |
| 2025-11-11 20:31:04 +0100 | <monochrom> | OK OK, s/archaeologists/ufologists/ ! >:D |
| 2025-11-11 20:30:10 +0100 | <tomsmeding> | I don't think this is a particularly convincing exhibit to that end :p |
| 2025-11-11 20:29:33 +0100 | fp | (~Thunderbi@89-27-10-140.bb.dnainternet.fi) fp |
| 2025-11-11 20:29:29 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Quit: Leaving...) |
| 2025-11-11 20:28:55 +0100 | <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 20:28:04 +0100 | <tomsmeding> | monochrom: are they? :P |
| 2025-11-11 20:27:31 +0100 | <EvanR> | (where UT is not exactly equal to UTC but close) |
| 2025-11-11 20:27:30 +0100 | <monochrom> | Oh, time leaps in IRC logs? They are awesome, please don't kill them! >:) |
| 2025-11-11 20:19:33 +0100 | <tomsmeding> | ok good, so it makes sense |
| 2025-11-11 20:19:18 +0100 | <tomsmeding> | oh right |
| 2025-11-11 20:19:04 +0100 | <EvanR> | wikipedia page has references to noon = noon in UT |
| 2025-11-11 20:19:01 +0100 | <lambdabot> | (19,16) |
| 2025-11-11 20:18:59 +0100 | <tomsmeding> | > (floor (0.80278 * 24), floor ((0.80278 * 24 - 19) * 60)) |
| 2025-11-11 20:18:25 +0100 | <tomsmeding> | (I just refreshed it) |
| 2025-11-11 20:18:19 +0100 | <tomsmeding> | ok so this table https://en.wikipedia.org/wiki/Julian_day#Variants seems to interpret it as relative to UTC |
| 2025-11-11 20:18:07 +0100 | Googulator8 | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-11 20:16:28 +0100 | dlock23 | (~dlock@user/dlock23) (Quit: Leaving) |
| 2025-11-11 20:15:57 +0100 | <EvanR> | now I'm going down a rabbit hole |
| 2025-11-11 20:15:49 +0100 | Googulator7 | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) |
| 2025-11-11 20:15:35 +0100 | <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 20:14:16 +0100 | <tomsmeding> | "Last modified 17/3/00" |
| 2025-11-11 20:14:00 +0100 | <EvanR> | wow nice css |
| 2025-11-11 20:13:23 +0100 | <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 20:11:13 +0100 | <EvanR> | yeah day (unless you're talking NASA MJD stuff) is really a localization thing |
| 2025-11-11 20:10:59 +0100 | <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 20:09:48 +0100 | <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 20:08:55 +0100 | <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 20:08:10 +0100 | <tomsmeding> | without DST I could just leave everything as-is and translate on-the-fly when serving the web page |
| 2025-11-11 20:07:15 +0100 | <tomsmeding> | DST should be abolished |
| 2025-11-11 20:06:49 +0100 | haltingsolver | (~cmo@2604:3d09:207f:8000:d250:ea0c:366a:6e73) |
| 2025-11-11 20:05:23 +0100 | <EvanR> | the fascinating problems we put ourselves in |
| 2025-11-11 20:04:44 +0100 | <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 20:03:26 +0100 | <tomsmeding> | it's whether it happened at 01:30 or 02:30 UTC |
| 2025-11-11 20:02:37 +0100 | tromp | (~textual@2001:1c00:3487:1b00:bd50:5f58:be67:a48d) |
| 2025-11-11 20:02:36 +0100 | <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 20:02:06 +0100 | <haskellbridge> | <Zemyla> Yeah, you just have to make sure the overlap isn't a problem. |
| 2025-11-11 20:01:45 +0100 | <tomsmeding> | that's a point |
| 2025-11-11 20:01:40 +0100 | <EvanR> | flip a coin |
| 2025-11-11 20:01:36 +0100 | <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 20:01:11 +0100 | <tomsmeding> | EvanR: possibly |
| 2025-11-11 20:01:04 +0100 | <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 |