Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    SYNCHRONET    |    Rob Swindell fetishistic worship forum    |    43,341 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 40,887 of 43,341    |
|    deon to Digital Man    |
|    JS Object save_msg()    |
|    21 Dec 24 19:26:48    |
      TZUTC: 1100       MSGID: 50243.dove-syncdisc@12:1/2 2bcc760b       REPLY: 53290.sync@1:103/705 2bcbdbc9       PID: Synchronet 3.20a-Linux master/7b932f63e Dec 9 2023 GCC 10.2.1       TID: SBBSecho 3.23-Linux master/445394f9f Dec 20 2024 GCC 12.2.0       COLS: 80       BBSID: ALTERANT       CHRS: CP437 2       NOTE: FSEditor.js v1.105        Re: JS Object save_msg()        By: Digital Man to deon on Fri Dec 20 2024 12:37 pm              Howdy,               > Looking/thinking more about the use of time_t for storage of date/time for        > posted messages because your questions (thank you for those), I do see a        > flaw, after all these years: If the system (OS) time zone is changed (beyond        > just annual daylight versus standard time changes), then the stored        > "when_written_time" values in message headers no longer actually reflect the        > "wallclock time" of the posted message, as was the intent.        >        > For example, I post/save a message right now and it reflects (correctly):        > Dec-20-2024 12:30 PM, PST and it stores the current time_t value that        > represents that (as can be seen with ctime, etc.).               > However, if I move to BBS to the U.S. east coast and change the system (OS)        > time zone setting that message is now reported as having been posted at:        > Dec-20-2024 03:30 PM, PST              Actually, I was pleased to see that messages are stored in time_t, and in fact       the "wall time" you mention is still valid? I think its the right approach,       because it doesnt represent that actual time a message was written (on your       system anyway).              IE: You posting a message at 12:30pm PST, isnt that 3:30pm on the east coast?       Its that PST (aka scfg -> system -> local time zone) setting that is messing       things. (I think - because that text is appended to the ctime() results.)              If that was removed, (or rather changed to control how time is *displayed*       only), and then reading messages can still be displayed in PST (if that is       what you wanted), or shown "local" time zone (EST? dont know what east cost       timezone is called).              (Additionally, it should be easier to allow users to show times in "their"       local time - if it wasnt PST/EST, or for that matter AEDT/+11:00 then you use       the users preferred timezone, instead of the system one when rendering a date.)              IE: Messages, as written as stored in utc (time_t), no change there.       When displaying a message, you set the timezone accordingly, then use ctime()?       (Dont know the c/c++ function to display time in a differnet timezone, but I       know it is manipulated by TZ environment variable right?              Showing age (which I do like in Sync), its easy to figure out how many hours       ago something was posted, by using time_t (utc ints).               > If someone posted at 4AM in their local        > time, that's usually what I want to see in the message header.              That I agree. Hence why I actually like the time offset appended to the time       (+11:00 in my case). When I see a message as ... 04:00:00 +06:00, and its 6pm       for me, I know immediately that it was written at 9am my time, and thus 9 hrs       ago. But I do agree the timezone string looks good too, just harder to the       math.                     ...лоеп              ---        ю Synchronet ю AnsiTEX bringing back videotex but with ANSI        * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)       SEEN-BY: 103/705 105/81 106/201 124/5016 128/187 153/757 7715 154/10       SEEN-BY: 154/30 203/0 218/700 221/0 226/30 227/114 229/110 114 206       SEEN-BY: 229/317 400 426 428 470 550 700 705 240/1120 5832 266/512       SEEN-BY: 280/464 5003 5006 282/1038 291/111 292/8125 301/1 310/31       SEEN-BY: 320/219 322/757 341/66 234 342/200 396/45 423/120 460/58       SEEN-BY: 460/256 1124 467/888 633/280 712/848 770/1 902/26 5020/400       SEEN-BY: 5054/30 5075/35       PATH: 103/705 280/464 460/58 229/426           |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca