Newest at the top
| 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 |
| 2025-11-11 19:51:52 +0100 | <EvanR> | how many haskell programmers does it take to get time and date right |
| 2025-11-11 19:51:48 +0100 | <haskellbridge> | <Zemyla> I'm pretty sure it's impossible, then. |
| 2025-11-11 19:51:35 +0100 | tomsmeding | checks if they're in the database |
| 2025-11-11 19:51:18 +0100 | <EvanR> | nice |
| 2025-11-11 19:51:14 +0100 | <tomsmeding> | but the website drops them |
| 2025-11-11 19:51:08 +0100 | <tomsmeding> | well the logs are still there in the plain znc logs |
| 2025-11-11 19:51:00 +0100 | <EvanR> | we lost logs or we will lose logs |
| 2025-11-11 19:50:49 +0100 | <tomsmeding> | anyway you can see the opposite jump here https://ircbrowse.tomsmeding.com/day/lchaskell/2025/03/30?id=1517022#trid1517022 |
| 2025-11-11 19:50:48 +0100 | Googulator8 | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) |
| 2025-11-11 19:50:42 +0100 | <sm> | no! atlantean calendar |
| 2025-11-11 19:50:38 +0100 | <EvanR> | you mean if you convert to UTC? |
| 2025-11-11 19:50:37 +0100 | Googulator8 | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-11 19:50:22 +0100 | <EvanR> | what |
| 2025-11-11 19:50:15 +0100 | <tomsmeding> | and I now see that means that we lose one hour of logs every october? |
| 2025-11-11 19:49:48 +0100 | <EvanR> | I vote to convert it to aztec calendar |