Newest at the top
| 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 |
| 2025-11-11 20:00:27 +0100 | <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 20:00:26 +0100 | <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:59:50 +0100 | <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:58:57 +0100 | lucabtz | (~lucabtz@user/lucabtz) (Remote host closed the connection) |
| 2025-11-11 19:57:33 +0100 | <tomsmeding> | Zemyla: so possible, but rather a nuisancve |
| 2025-11-11 19:57:14 +0100 | <tomsmeding> | I have wanted to rewrite this system for years but I never had the motivation to |
| 2025-11-11 19:56:55 +0100 | <tomsmeding> | and people might have bookmarks to specific events, which have the ID in the URL |
| 2025-11-11 19:56:41 +0100 | <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 19:56:19 +0100 | <tomsmeding> | ok so the logs are there in the znc log files but the import to postgres borks |
| 2025-11-11 19:55:25 +0100 | Zemyla | (~Zemyla@72.178.108.235) (Quit: Client closed) |
| 2025-11-11 19:52:43 +0100 | <tomsmeding> | and 2. me not doing that |
| 2025-11-11 19:52:36 +0100 | <tomsmeding> | and apparently assuming that the server is in UTC |
| 2025-11-11 19:52:31 +0100 | <humasect> | it will be evaluated when necessary |
| 2025-11-11 19:52:25 +0100 | <tomsmeding> | well this is a combination of 1. the original author of ircbrowse creating this hideous postgres setup |