@MSGID: 2:310/31.3@fidonet deea59b5
@PID: OpenXP/5.0.41 (Linux) (x86_64)
@CHRS: ASCII 1
@TZUTC: 0000
Greetings All!
Would somebody please confirm that there is *NO* TZUTC kludge in the message header, thanks.
Regards,
Martin
--- OpenXP 5.0.41
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)
SEEN-BY: 103/705 154/10 203/0 221/0 1 6 360 229/426 240/1120 5832
280/464
SEEN-BY: 280/5003 5555 310/31 313/41 320/119 219 396/45 423/81 120 640/1138
SEEN-BY: 640/1321 1384 712/848 770/1 2452/250 3634/12
@PATH: 310/31 280/464 221/1 640/1384
@MSGID: 2:310/31.3@fidonet deea59b5
@PID: OpenXP/5.0.41 (Linux) (x86_64)
@CHRS: ASCII 1
@TZUTC: 0000
Greetings All!
Would somebody please confirm that there is *NO* TZUTC kludge in the message header, thanks.
Regards,
Martin
SEEN-BY: 310/31
@MSGID: 2:310/31.3@fidonet deea59b5
@PID: OpenXP/5.0.41 (Linux) (x86_64)
@CHRS: ASCII 1
@TZUTC: 0000
Greetings All!
Would somebody please confirm that there is *NO* TZUTC kludge in the message header, thanks.
^^^^^^^^^^^^@MSGID: 2:310/31.3@fidonet deea59b5
@PID: OpenXP/5.0.41 (Linux) (x86_64)
@CHRS: ASCII 1
@TZUTC: 0000
^^^^^^^^^^^^^^^^Greetings All!
Would somebody please confirm that there is *NO* TZUTC kludge in the
message header, thanks.
Looks sparklin', Martin. ;)
Not confirmed.
Still 0000
30 Nov 2019 10:45, from Martin Foster -> All:
@MSGID: 2:310/31.3@fidonet deea59b5
@PID: OpenXP/5.0.41 (Linux) (x86_64)
@CHRS: ASCII 1
@TZUTC: 0000
Greetings All!
Would somebody please confirm that there is *NO* TZUTC kludge in the
message header, thanks.
@MSGID: 2:310/31.3@fidonet deea59b5
@PID: OpenXP/5.0.41 (Linux) (x86_64)
@CHRS: ASCII 1
@TZUTC: 0000
Greetings All!
Would somebody please confirm that there is *NO* TZUTC kludge in the
message header, thanks.
It is still there but that is not a problem.. :)
Would somebody please confirm that there is *NO* TZUTC kludge in
the message header, thanks.
It is still there but that is not a problem.. :)
Please see my reply to Paul Quinn, thanks.
@MSGID: 2:310/31.3@fidonet df025d5f
@REPLY: 3:640/1384 5de24a91
@PID: OpenXP/5.0.41 (Linux) (x86_64)
@CHRS: ASCII 1
Would somebody please confirm that there is *NO* TZUTC kludge in
@MSGID: 2:310/31.3@fidonet df025d5f
@REPLY: 3:640/1384 5de24a91
@PID: OpenXP/5.0.41 (Linux) (x86_64)
@CHRS: ASCII 1
Hello Paul!
I've tweaked my config and the kludge should *not* be present in the message header in this reply. Please confirm, thanks.
Thanks but the kludge should *not* have been there. I suspect
that this was "operator error" on my part, sorry.
I've tweaked my config and the kludge should *not* be present
in the message header in this reply. Please confirm, thanks.
Stupid question coming..
Why would anyone need to turn TZUTC off and on? ..or, is this an exclusive/temporary developer feature to make sure things don't break going up the chain and so that you can continue to use the same program with in 5.0.41 without having to keep swapping the previous
version? If so, nice!
I appreciated such a facility with my Win32 JamNNTPd server
which ran on my dear-departed Win98se node. Without fail,
every summer it would indicate DST incorrectly. We
don't 'do' DST in this locale; never have, besides stoopid
trials. So I turned its TZUTC=off permanently. Sweet. :)
Why would anyone need to turn TZUTC off and on?
I appreciated such a facility with my Win32 JamNNTPd server
I never ran Win98se for BBS operations. I started with OS/2 2.1 and used the built-in Win support for launching win-specific bbs programs. I
never seemed to have a problem honouring ZMH that I recall.
@MSGID: 2:310/31.3@fidonet df025d5f
@REPLY: 3:640/1384 5de24a91
@PID: OpenXP/5.0.41 (Linux) (x86_64)
@CHRS: ASCII 1
Hello Paul!
I've tweaked my config and the kludge should *not* be present in the
message header in this reply. Please confirm, thanks.
True, yes. OTOH the first was properly formed per format and informational content.
Would somebody please confirm that there is *NO* TZUTC kludge in
the message header, thanks.
It is still there but that is not a problem.. :)
Please see my reply to Paul Quinn, thanks.
It's not there now.
Is it reporting the wrong TZ or is there a reason why you don't
want it?
@MSGID: 2:310/31.3@fidonet df025d5f
@REPLY: 3:640/1384 5de24a91
@PID: OpenXP/5.0.41 (Linux) (x86_64)
@CHRS: ASCII 1
Would somebody please confirm that there is *NO* TZUTC kludge in
Thanks but the kludge should *not* have been there. I suspect
that this was "operator error" on my part, sorry.
I've tweaked my config and the kludge should *not* be present
in the message header in this reply. Please confirm, thanks.
Stupid question coming..
Why would anyone need to turn TZUTC off and on?
..or, is this an exclusive/temporary developer feature to make
sure things don't break going up the chain and so that you can
continue to use the same program with TZUTC=off in 5.0.41 without
having to keep swapping the previous version? If so, nice!
@TZUTC: 0000
OK, thanks for confirming and for the heads-up :)
BTW ... TZUTC kludge is now back on ;)
@MSGID: 2:310/31.3@fidonet df0a5e88
@REPLY: 3:640/1384 5de39795
@PID: OpenXP/5.0.41 (Linux) (x86_64)
@CHRS: ASCII 1
@TZUTC: 0000
BTW ... TZUTC kludge is now back on ;)
BTW ... TZUTC kludge is now back on ;)It is indeed. But are you sure it is correct? You reside UTC+0 ?
Why would anyone need to turn TZUTC off and on?
..it's the way the developer decided to implement it, thus giving the user the option to enable/disable it.
@MSGID: 2:310/31.3@fidonet df0a5e88
@REPLY: 3:640/1384 5de39795
@PID: OpenXP/5.0.41 (Linux) (x86_64)
@CHRS: ASCII 1
@TZUTC: 0000
BTW ... TZUTC kludge is now back on ;)
BTW ... TZUTC kludge is now back on ;)
It is indeed. But are you sure it is correct? You reside UTC+0 ?
UK Winter time ... should be OK
Why would anyone need to turn TZUTC off and on?
..it's the way the developer decided to implement it, thus giving the
user the option to enable/disable it.
Is the TZUTC coming from the OSes setting?
..or will we be able to override/tweak it in OXP to mess with
people's minds? <BWG>
Although I point off Richard's system in Austria(CET(UTC+1)), I live
in the UK(GMT(UTC+0)) :)
Why would anyone need to turn TZUTC off and on?
..it's the way the developer decided to implement it, thus giving the
user the option to enable/disable it.
Is the TZUTC coming from the OSes setting?
That's something I've been wondering about so I'll ask the developer.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 508 |
Nodes: | 16 (2 / 14) |
Uptime: | 26:48:03 |
Calls: | 9,996 |
Calls today: | 6 |
Files: | 13,840 |
Messages: | 6,360,829 |
Posted today: | 1 |