Newsgroup: it.comp.software.newsreader
Titolo: Re: slrn: due anomalie

 nei reply non appare. Possibile?
Se guardi bene c'č anche `set followup_custom_headers'...
Ciao.
-- 
 /   _ _ | Xnews e la documentazione in italiano
( (/( (/ | 
http://web.lacasadialice.it/alanford/

 perchè? mica sono a Greenwich
L'importante è che poi però il risultato sia un orario giusto, 
e mi sembra che lo sia, vero? Sei sicuro che sia una cosa scritta dal
programma? Potrebbe essere il servernews che sovrasccrive la data? ad es.
lo fa quello di infostrada se guardi i miei accade la stessa cosa

 No, anche perchè, sempre sullo stesso server un altro client da questo:
Invece è così, perché SLRN *non* genera l'header Date, dato che è
compito del server farlo.
Il fatto che un altro newsreader visualizzi la data in CEST è del tutto
irrilevante: l'altro NUA potrebbe forzare la creazione dell'header.
Se vuoi forzare la generazione dell'header Date con SLRN, usa:
	set generate_date_header 1
Come da manuale di SLRN:
| 6.37.  generate_date_header
| Type: integer
| Default: 0
| 
| Usually, the generation of ``Date:'' header lines can be left to the
| server.  If it does not do this correctly, please complain to its
| administrator, as a working system clock is essential for a news
| server.
|
| That being said, you can still have slrn generate that header line
| itself by changing this variable; you might want to use this to make
| postings sent via slrnpull reflect the time they were written.
| However, please note that this might lead to articles being rejected
| if your system clock does not work correctly or an outgoing post was
| left in the queue for a long time.
Ergo, è *estremamente* sconsigliato farlo.
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)                 [ 
http://www.emmanuelebassi.net
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

compito del server farlo.
Non proprio :)
Cito la documentazione in proposito:
|2.1.2.  Date
|
|    The "Date" line (formerly "Posted") is the date that the message was
|    originally posted to the network.
[...]
[RFC 1036]
|          5.1. Date
|
|          The  Date header contains the date and time when the article
|          was submitted for transmission: 
[...]
[Son of 1036]
|5.1.  Date
|
|   The Date-header contains the date and time that the article was
|   prepared by the poster ready for transmission and SHOULD express the
|   poster's local time. The content syntax makes use of syntax defined
|   in [RFC 2822] (but see the revised definition of zone in section
|   2.4.3).
|
|      header              =/ Date-header
|      Date-header         = "Date" ":" SP Date-content
|      Date-content        = date-time
|
|   The date-time MUST be semantically valid as required by [RFC 2822].
|   Although folding white space is permitted throughout the date-time
|   syntax, it is RECOMMENDED that a single space be used in each place
|   that FWS appears (whether it is required or optional).
|
|   The date-time MUST NOT be more than 24 hours into the future
|   (injecting agents will reject such articles, possibly even when the
|   margin is less than 24 hours - see 8.2.2 - and MAY also reject them
|   if it is inordinately far into the past).  Relaying agents MUST NOT
|   modify the Date-header in transit. 
[draft for usefor 13]
Se la 1036 e la son-of si limitano a specificare che «Date» rappresenta la
data dell'inserimento dell'articolo nella rete, il draft sottolinea invece
chiaramente che tale header deve contenere la data del momento nel quale è
stato preparato l'articolo (mentre per indicare quando è stato preparato è
previsto l'header «NNTP-Posting-Date»).
In altre parole: non è mai sottolineato di chi sia compito creare l'header
in questione. Solo che dai vecchi documenti si può evincere che può essere
sia il server che il client a farlo, mentre nel nuovo draft che sostituirà
le altre RFC e pseudo-RFC, questa possibilità è esclusa, a favore però del
client, non del server.
Credo che sarebbe scorretto dire che il comportamento di SLRN è sbagliato,
almeno per il momento; se però il draft, come è dato per scontato, diverrà
RFC, anche il suddetto software dovrà adeguarsi ai nuovi standard.
Non credo sarà un gran problema! :)
-- 
Ciao, Massimo | ICQ# 57669970 | Jabber: 
pet...@jabber.linux.it
- La bellezza salverà il mondo. -