Text 17782, 73 rader
Skriven 2015-10-02 14:52:32 av mark lewis (1:3634/12.73)
  Kommentar till text 17781 av Maurice Kinal (1:153/7001.0)
Ärende: strftime list
=====================
02 Oct 15 17:11, you wrote to Wilfred van Velzen:

 MK> @REPLY: 2:280/464 560eb267
 MK> @MSGID: 1:153/7001.0 560ebac8
 MK> @TID: WeBeBashing 3.0
 MK> -={ vrijdag, 02 oktober 2015, 19:11:36 +0200 }=-

 MK> Hey Wilfred!

 WvV>> Anyway there seems to be something wrong with your UTC time!

 MK> Not when it leaves here.  Somewhere it is getting corrupted.

if it is then a system in the path or over where you are reading them is
breaking them...

 MK> For the record this reply shows "02 Oct 15  17:11:36" in the header.

that's exactly what it shows here on this point, my main system and on a SBBS
system that's carrying the area and hosted over here... so none of the 3 or 4
systems between you and me are breaking it... that means it is somewhere else
outside of the backbone...

 MK> It will be different on every BBS I have seen my posts/replies posted
 MK> in as they seem to want to convert it to whatever they think it should
 MK> be rather than what it actually is.

it should not be unless they are unable to determine the timezone since there's
no control line ;)

 MK> Check the raw pkt to see if that is the case please.

 MK> Also "02 Oct 15  17:11:36" is exactly 2 hours different than "vrijdag,
 MK> 02 oktober 2015, 19:11:36 +0200" which is what I am sending in the
 MK> packed msg. If you see different than it seems to me that my
 MK> additional nonFTN datetime stamp (between the -={ and }=- characters)
 MK> is indeed superior to the packed msg header which is more ammunition
 MK> in my favour when I claim that the FTSC is corrupting data.  The only
 MK> way I could improve it is to change it to RFC-3339 format.

the message header should contain the time the message was written... that time
may be either local or UTC... there was no control line needed back in the day
because when it started, everyone was using the same software so there was no
need... then things changed and some networked systems use UTC while others do
not... /none/ of my networked machines have ever used UTC and never will ;)

 WvV>> 'TZUTC: 0000' kludge

 MK> Errrr ... TZUTC: +0000 would be correct.  0000 is corruption by
 MK> definition since it lacks the + character as per real world standards
 MK> for utc offsets.

we're no using ""real world standards for utc offsets"... this is fidonet and
we use fidonet standards... in this case, the fidonet standard specifically
states that the '+' is not used... it is obvious that the value is positive or
negative just by looking at it since the negative must be accompanied by a
'-'...

 MK> Anyone who says different should be taken out back to the woodshed for
 MK> applied corrective measures.  :::evil grin:::

you first! :)

 MK> Again I must quote Alexey Vissarionov when he said, "For the FTN node,
 MK> that's just stupid."

too bad you keep leaving out the rest of the context of alexey's statement...

)\/(ark

... Let me have a McFry, a McHamburger and the right McChange.
---
 * Origin:  (1:3634/12.73)