ml>> ok, tell me what you'd do with this message... this is a FTN
 ml>> message being forwarded in a FTN network...

 ml>> Sat  3 Aug 96 20:48

 RvdW> WaterGate detects this and says "shit, Seadog style date", then

shit! do you believe i posted the wrong one? >  that
one was the original message he wrote to me in the echo packed into his
outbound PKT file going to his feed. he intercepted it and sent it to me so
that we could see that his site is producing proper seadog style time/date
stamp on it...

try this one instead... this is how that same message appeared when it
arrived here after travelling thru 6 systems... at least one of them is
using software that cannot convert the time/date stamp correctly and also
passes converted stuff down the pipe instead of unaltered copies...

000630                          02 00 0F 00 0C 00 32 0E          ......2.
000640  32 0E 00 00 00 00 30 33 20 41 75 67 20 39 36 20  2.....03 Aug 96
000650  32 30 3A 34 38 00 4D 61 72 6B 20 4C 65 77 69 73  20:48.Mark Lewis
000660  00 4E 6F 72 6D 61 6E 20 50 65 65 6C 6D 61 6E 00  .Norman Peelman.
000670  48 65 79 21 00 41 52 45 41 3A 53 59 53 4F 50 31  Hey!.AREA:SYSOP1
000680  38 0D 01 50 49 44 3A 20 50 44 51 4D 61 69 6C 20  8..PID: PDQMail
000690  76 32 2E 36 30 20 52 45 30 37 32 32 0D 4D 61 72  v2.60 RE0722.Mar
0006A0  6B 2C 0D 0D 20 20 20 20 20 49 20 77 61 73 20 67  k,..     I was g
0006B0  6C 61 64 20 74 6F 20 68 65 61 72 20 66 72 6F 6D  lad to hear from
0006C0  20 79 6F 75 20 63 6F 6E 63 65 72 6E 69 6E 67 20   you concerning
0006D0  74 68 65 20 70 72 6F 62 6C 65 6D 73 20 77 65 20  the problems we
0006E0  61 72 65 20 64 69 73 63 75 73 73 69 6E 67 2E 20  are discussing.
0006F0  49 20 77 69 6C 6C 20 73 65 6E 64 20 79 6F 75 20  I will send you
000700  77 68 61 74 20 79 6F 75 20 6E 65 65 64 20 76 69  what you need vi
000710  61 20 66 69 6C 65 20 61 74 74 61 63 68 2E 20 3A  a file attach. :
000720  29 0D 0D 46 69 64 6F 4E 45 54 3A 0D 4E 6F 72 6D  )..FidoNET:.Norm
000730  61 6E 20 50 65 65 6C 6D 61 6E 0D 31 3A 33 36 33  an Peelman.1:363
000740  2F 33 31 35 0D 0D 49 6E 74 65 72 4E 45 54 3A 0D  /315..InterNET:.
000750  4E 6F 72 6D 61 6E 2E 50 65 65 6C 6D 61 6E 25 33  Norman.Peelman%3
000760  31 35 40 73 61 74 6C 69 6E 6B 2E 6F 61 75 2E 6F  15{at}satlink.oau.o
000770  72 67 0D 0D 2D 2D 2D 20 44 4C 47 20 50 72 6F 20  rg..--- DLG Pro
000780  76 31 2E 31 75 34 2F 50 44 51 4D 61 69 6C 20 76  v1.1u4/PDQMail v
0007A0  20 54 68 65 20 54 48 49 52 44 20 44 69 6D 65 6E   The THIRD Dimen
0007B0  73 69 6F 6E 20 28 34 30 37 29 2D 33 35 39 2D 30  sion (407)-359-0
0007C0  38 34 30 20 59 65 73 2C 20 41 4D 49 47 41 21 20  840 Yes, AMIGA!
0007D0  28 31 3A 33 36 33 2F 33 31 35 29 0D 0A 53 45 45  (1:363/315)..SEE
0007E0  4E 2D 42 59 3A 20 31 38 2F 31 39 20 31 31 32 2F  N-BY: 18/19 112/
0007F0  32 38 35 20 31 31 36 2F 32 37 20 31 33 35 2F 32  285 116/27 135/2
000800  39 32 20 32 37 30 2F 31 30 31 20 33 36 33 2F 33  92 270/101 363/3
000810  20 31 31 38 20 31 32 39 20 31 35 37 20 31 36 38   118 129 157 168
000820  0D 53 45 45 4E 2D 42 59 3A 20 33 36 33 2F 32 36  .SEEN-BY: 363/26
000830  34 20 33 31 35 20 36 30 33 20 31 35 37 31 20 33  4 315 603 1571 3
000840  36 35 2F 31 30 30 30 20 34 35 30 31 20 33 36 36  65/1000 4501 366
000850  2F 32 37 20 32 32 31 20 33 36 39 2F 36 39 20 33  /27 221 369/69 3
000860  37 32 2F 36 32 0D 53 45 45 4E 2D 42 59 3A 20 33  72/62.SEEN-BY: 3
000870  37 33 2F 31 20 33 37 34 2F 31 34 20 39 38 20 33  73/1 374/14 98 3
000880  37 35 2F 31 30 30 20 33 37 36 2F 31 34 30 20 33  75/100 376/140 3
000890  37 39 2F 31 20 33 36 30 31 2F 31 34 20 33 36 30  79/1 3601/14 360
0008A0  33 2F 33 36 31 20 34 32 30 0D 53 45 45 4E 2D 42  3/361 420.SEEN-B
0008B0  59 3A 20 33 36 30 33 2F 35 37 30 20 33 36 30 37  Y: 3603/570 3607
0008C0  2F 31 30 20 33 36 30 38 2F 35 20 33 36 30 39 2F  /10 3608/5 3609/
0008D0  36 34 20 33 36 31 33 2F 37 20 33 36 31 37 2F 31  64 3613/7 3617/1
0008E0  32 20 33 36 31 39 2F 31 20 31 38 0D 53 45 45 4E  2 3619/1 18.SEEN
0008F0  2D 42 59 3A 20 33 36 31 39 2F 32 31 20 32 35 20  -BY: 3619/21 25
000900  33 36 32 30 2F 39 20 33 36 33 33 2F 33 36 20 33  3620/9 3633/36 3
000910  36 33 34 2F 31 32 20 31 35 20 32 32 20 33 37 20  634/12 15 22 37
000920  33 36 33 36 2F 32 20 33 36 33 39 2F 37 36 0D 53  3636/2 3639/76.S
000930  45 45 4E 2D 42 59 3A 20 33 36 34 35 2F 32 30 20  EEN-BY: 3645/20
000940  33 36 35 32 2F 31 20 33 36 35 34 2F 35 20 33 36  3652/1 3654/5 36
000950  36 31 2F 36 30 34 20 33 36 36 36 2F 34 30 31 0D  61/604 3666/401.
000960  01 50 41 54 48 3A 20 33 36 33 2F 33 31 35 20 31  .PATH: 363/315 1
000970  32 39 20 31 31 38 20 31 35 37 20 33 36 31 39 2F  29 118 157 3619/
000980  32 35 20 33 36 33 34 2F 32 32 20 31 35 0D 00 00  25 3634/22 15...
000990  00                                               .

since 363/315 is producing compliant time/date strings, that leaves at
least one of these systems to do the mangling... 363/129 363/118 363/157
3619/25 3634/22 or 3634/15

  3619/25 is my REC. his site is running amiga stuff for the major
  mail moving. it is he that says his software author is going to
  put in a "special check" for DLGPro or PDQMail which is NOT the
  "proper" check to put in. he cannot tell me, or he hasn't anyway,
  if these messages come into his system properly formatted or if
  they leave his system properly formatted.

  3634/22 is my NC. he is running squish stuff if i'm not mistaken.

  3634/15 is my hub for regional stuff. he is running d'bridge v1.58
  if i remember rightly...

 RvdW> removes the "Sat " part and inserts an extra space
between the date
 RvdW> and time and adds seconds, resulting in:

 RvdW> " 3 Aug 96  20:48:00"

 RvdW> And since a few minutes (after checking fts-0001) it will make sure
 RvdW> the day is 0-filled, and thus results in:

 RvdW> "03 Aug 96  20:48:00"

i can see doing this for LOCAL STORAGE but not in those messages being
repacked and sent on down the pipe to other systems! doesn't this go
against the grain of "unaltered" ???

 ml>> i'll tell you exactly what the problem is... it is a screwed
 ml>> up implementation of forwarding code WRT opus/seadog date
 ml>> formats. in forwarded messages, the date format should be
 ml>> the same as it was when the message left the originating
 ml>> system, correct?

 RvdW> Eh, yes. But, the date _is_ the same. I just formatted it a bit
 RvdW> different ;)

with my screwup, you did properly convert the date from seadog format to
fido format... take a look at the above hex dump, though...

 ml>>  yes, i understand and recognise the need to convert the dates
 ml>>
 ml>> when importing to the message base but this should NOT (imo)
 ml>> be done on forwarded messages.

 RvdW> This is what I do: I do the date checking and conversion when I
 RvdW> read the messag from a .PKT file. I store the corrected format and
 RvdW> this reduces the requirements on the rest of the code. If I happen
 RvdW> to write the message out again, then I use the corrected format.
 RvdW> This will be the same format in 99% of the cases and a corrected
 RvdW> format in the rest of the cases.

i still don't understand... "reduced requirements" ?? hunh? for
local storage, do whatever... for passing on down the line, simple reading
and writting of unaltered bytes is all that's needed other than the minor
seen-by, path, and header net/node changes... nothing else should be
altered from the original IF the mail mangler is going to pass the message
on down the line.

if the above paragraph was in use everywhere, then the above hex dump would
not happen!!! think about that! convert nothing, alter only what is
necessary, pass on conforming stuff and sideline/bounce non-conforming
stuff...

)\/(ark