The problem is in the network management spec. From the Phase IV spec,an event message contains an "event time" encoded as follows: EVENT TIME Is the source node date and time of event processing. Consists of: JULIAN SECOND MILLISECOND HALF DAY where: JULIAN HALF DAY (2) : B Number of half days since 1 Jan 1977 and before 9 Nov 2021 (0-32767). For example, the morning of Jan 1, 1977 is0. SECOND (2) : B Second within current half day (0-43199). MILLISECOND (2) : B Millisecond within current second (0-999). If not supported, high order bit is set, remainder are clear, and field is not printed when formatted for output. Note "before 9 Nov 2021". The obvious fix is to disregard the "0-32767" comment, which tells us to treat it as a 15-bit value, and make it 16 bits instead. I did that in DECnet/E, and in PyDECnet. I suspect VMS could be patched to do the analogous fix, but I have no idea how to do that. paul _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

On Nov 13, 2024, at 12:50 PM, John Forecast <john(a)forecast.name> wrote: Depends on the implementation. Nov 9, 2021 on VMS, Ultrix and probably some others. RSX is good until 2065. John. _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

The statement in the DECnet spec that julian half-day is 15 bits is an obvious bug with an obvious fix; clearly RSX and others have made that fix.  VMS needs to do likewise. paul _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

On Nov 13, 2024, at 1:53 PM, Johnny Billquist <bqt(a)softjar.se> wrote: I would not call it a bug. It was initially defined that way. However, RSX officially decided to start treating it as an unsigned 16-bit value with the last releases, and documented this. And it's a change that do make sense. But if others have not applied the same update, then it makes sense that they would zero the value if it have the high bit set. Johnny On 2024-11-13 19:26, Paul Koning wrote: -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

Well. Bad design is not the same as "bug" either. ;-) I would suspect the author had some reason (good or bad) for defining it the way it was. I think extending it to unsigned 16 bits is a very straight forward and obvious way to fix this. But to be honest, I think the whole format is completely broken to begin with. Either just specify it as seconds (or days) after some epoch, or have separate fields for each component. Julian half-days? Who on earth came up with that idea? The formula is just horrific: JULIAN = (3055*(MONTH+2)/1OO-(MONTH+10)/13*2-91+(1-(YEAR-YEAR/4*4+3)/4)*(MONTH+10)/13+DAY-1+(YEAR-1977)*365+(YEAR-1977)/4)*2   Johnny On 2024-11-13 20:20, Paul Koning wrote:

On Nov 13, 2024, at 4:18 PM, Paul Koning <paulkoning(a)comcast.net> wrote: It is to me, and I worked in that group.

By that definition, we still have a bug. Changing to unsigned 16 bits only gives us a few more years...

------------------------------------------------------------------------ It could still have been done so much cleaner.