Newsgroup: it.comp.lang.visual-basic
Titolo: Problema con anno a 2 cifre...

Ho trasportato la mia applicazione in ASP (vbscript) su un portatile.
Dopo il trasporto, si verifica una cosa stranissima, le funzioni Date() e
Now() mi restituiscono l'anno a 2 cifre anzichč a 4 cifre, creando problemi
a tutte le funzioni di gestione delle date che ho realizzato.
LCID č impostato a 1040 e quindi non viene tenuto conto dei settaggi
regionali (ho provato a cambiarli, ma la data resta corretta in formato
gg/mm/aa) ma per scrupolo nei settaggi regionali l'anno č impostato
ovviamente a 4 cifre.
Ancora.. usando DateAdd("H",1,"26/04/2004 22.00") mi viene restituito:
26/04/04 22.00
OS: WinXP IIS6 (?) e... e basta.. e ASP Classic (vbscript).
Qualche suggerimento? Le MDAC vengono tirate in ballo anche per funzioni
interne del motore di scripting di vbscript? Settaggi del bios?
Non so piů che pesci prendere...
-- 
:: Massimiliano Mattei
:: Project Leader
:: EVA Group :: 
www.evagroup.net
:: Soluzioni extranet :: e-business :: corporate portal

Purtroppo il problema è dovuto a come il sistema gestisce le date.
Su Win98 era a 2 cifre, su nt (e famiglia) è a 4 cifre.
Non so se è possibile modificare qualcosa, ma io ho risolto facendo ogni
volta la conversione a 4 cifre.
Se trovi un metodo migliore dimmelo che mi risolvi non pochi problemi.
bye
-- 
Esistono 10 tipi di persone: chi conosce il binario e chi no.
Gestione Ottica - Gestionale per Ottici e Programmi Gratuiti su:
http://www.nicolaottomano.it

Questo però è Windows XP posso capire il cambio di millenio sul 98 e OS
dell'epoca però ormai... è veramente strano.. io intanto continuo a cercare
la radice del male, prima di rimettere mano alle funzioni... se scopro
qualcosa per primo vi aggiorno.. :)


Ok... ecco la radice del male.. risiede nel registro:
[HKEY_CURRENT_USER\Control Panel\International]
"Locale"="00000410"
"sShortDate"="MM/dd/yyyy"
[HKEY_USERS\.DEFAULT\Control Panel\International]
"Locale"="00000410"
"sShortDate"="MM/dd/yyyy"
Nella prima le impostazioni erano corrette, ma nella seconda chiave
risultava MM/dd/yy!!!
Se non dovesse bastare, esportate le chiavi da un pc con la configurazione
corretta e importatele nell'altro.



E farlo più semplicemente da  Pannello di controllo
Impostazioni internazionali?
-- 
----------------------------
Mauro Gamberini

 realizzato.
Date e Now restituiscono una data, e in quanto tale la restituiscono non
formattata, ossia nè a 2 nè a 4 cifre.
Solo se nel tuo codice utilizzi delle conversioni implicite, puoi avere
problemi. Ad esempio nel dateadd che riporti, c'è un CDate implicito, e il
CDate risente delle impostazioni internazionali nel registry.
La cosa peggiore che si possa fare è cambiare le impostazioni del Pc, perchè
si tratta di cose di sistema, e quindi non 'di proprietà' della tua
applicazione.
La soluzione corretta è quella di utilizzare esclusivamente conversioni
esplicite (come comunque andrebbe fatto sempre, per evitare bug
introvabili), e utilizzando funzioni 'localizzate' (CDate, CStr,...) o
'assolute' (Format$, DateSerial,...) in funzione di ciò che ti serve.
Ciao
Alberto

 la radice del male
La radice del male è che vi ostinate a gestire le date come se fossero 
stringhe.
Non è così!
L'anno 2010 è 2010 anche se viene scritto come 10.
Ciao

 avere problemi.
già.
più che implicite, bisognerebbe chiamarle criptoconversioni.
-- 
Salutoni
Sergio
per rispondere... togli il group dall'indirizzo

 configurazione corretta e importatele nell'altro.
Avevo gią trovato queste chiavi non molto tempo fa, ma il problema č che non
voglio modificare le impostazioni di sistema dell'utente.
Preferirei qualcosa che mi restituisca la data su 4 cifre nel mio prog, e
non nel sistema in generale.


 Impostazioni internazionali?
In teoria si. In pratica non puoi dire all'utente "modifica le impostazioni
manualmente". Devi farlo tu da VB.
E comunque non vado matto per le modifiche permanenti al sistema. La
soluzione del problema deve essere da qualche altra parte.


 prog, e non nel sistema in generale.
La data non ha un numero di cifre.
E' una cosa oramai detta fino alla nausea.
Esiste una memorizzazione e una visualizzazione.
Questo vale per qualunque variabile.
Dire che 'una variabile data ha due/quattro cifre' è una cosa che rasenta il
delirio.
Al limite, sarà la sua visualizzazione che ha un numero di cifre, ma se poi
devo usare la data in funzioni, calcoli, ecc.., dovrò usare la sua
memorizzazione, non la sua visualizzazione.
I casini nascono dal fatto che questa distinzione (che, comunque, è alla
base dell'informatica, e certe volte mi stupisco che non sia chiara a gente
brava) non venga rispettata.
Se vuoi l'anno, usi Year, ma non ti torna un numero di cifre neanche questo,
ti torna un Integer, che poi tu puoi trasformare in stringa con Format,
CStr, ecc...
Ciao
Alberto

Forse non mi sono spiegato bene all'inizio...
Nelle impostazioni internazionali era già settato gg/mm/aaaa


 Nelle impostazioni internazionali era già settato gg/mm/aaaa
si, questo si era capito.
il problema, probabilmente, è che nel sistema operativo che usi le
impostazioni internazionali non sono fisse ed immutabili, ma dipendono
dall'utente che sta eseguendo il codice, e io, sinceramente, non ho mai
capito quale sia l'utente che esegue il codice delle pagine asp.
comunque, come altrove ti è stato detto, stai combattendo con un falso
problema, e quello che hai messo in campo è una falsa soluzione.
poi, se tu sei contento così...



A me il problema si pone nella MaskEditBox, dove sono costretto ad assegnare
preventivamente un formato di data.
Poi, purtroppo, la MaskEd ti restituisce una stringa... che sei costretto a
convertire in data.


Beh si abbastanza soddisfatto direi.
In realtà essendo una applicazione ASP gira su un server e non è una
applicazione locale, quindi la filosofia è diversa.
Non si costringe nessun utente a cambiare nessuna impostazione, tanto è vero
che attualmente la maggior parte delle extranet che ho sono su server
americani, senza alcun bisogno di modificare nessuna impostazione regionale
ed ogni utente è libero di scegliersi il formato data che vuole.
L'unico vero problema è con l'anno espresso a due cifre, che per quanto mi
riguarda, in un server degno di tale nome ormai non dovrebbe più essere
settato e infatti in tutte le compagnie di hosting che ho utilizzato,
italiane e non, non si è mai verificato. Se l'applicazione è in housing
ancora meno problematico...
Non vedo il motivo di tanta polemica.. ma credo che purtroppo sia una tara
di noi programmatori questa di polemizzare.


 dovrebbe piů essere settato
m.mattei, che ti devo dire?
a mio avviso non hai capito il "cuore" del problema, ma, ripeto, se sei
contento cosě, continua pure ad esporre il fianco alle impostazioni del
pannello di controllo.


 Non vedo il motivo di tanta polemica.. 
Beh, quando dovrò darti 100 euro ti darò una banconota con scritto 10 a 
cui avrò aggiunto uno zero a penna, tanto non è il valore della 
banconota che importa, ma quello che c'è scritto.
Ciao

 
Ha ragione lui, sei polemico!
:-)
	maxx
-- 
NOSPAM: Rimuovere i trattini dallo username!
Cut hyphens from my username!

 costretto a convertire in data.
Esempio perfetto.
E' il classico caso dove sei obbligato ad usare DateSerial, altrimenti sei
esposto.
Ciao
Alberto

 tara di noi programmatori questa di polemizzare.
Non è polemica.
Si cercava di farti capire che stai ragionando al contrario, nel senso che
hai usato una programmazione 'esposta' alla localizzazione, e poi cerchi di
porre rimedio modificando l'ambiente.
Se tu vuoi imparare e uscire da un equivoco in cui rischi di affondare, qui
c'è di che imparare. Se sei convinto che sia solo polemica, fai pure.
ciao
Alberto

Ho capito benissimo il punto della discussione.
Come dicevo prima perň il problema non č con la localizzazione, tant'č che
ho le applicazioni su server americani con il formato data mm/gg/aaaa cosě
come li ho su server italiani.
Ho delle funzioni che mi filtrano le date in modo che queste siano
indipendenti dalle impostazioni regionali del server web e del server DB e
addirittura permettono ad ogni singolo utente di impostarsi il formato a
piacimento.
L'unico problema, che evidentemente non avevo calcolato nelle funzioni di
manipolazione delle date, č con l'anno a 2 cifre che ormai, dal passaggio
del millenio, non dovrebbe piů essere utilizzato in alcun server a mio
avviso e cosě č infatti per tutti i server di cui mi sono avvalso per
l'hosting, indipendentemente dalle impostazioni locali.
Dovrei riscrivere le funzioni per prevedere la presenza dell'anno a 2
cifre.. poi perň ci sarebbero da affrontare tutta un'altra serie di
problemi, come ad esempio l'inserimento da parte degli utenti di anni
prossimi al 1900.
Come dicevo prima credo che ormai il problema dell'anno a 2 cifre sia stato
ampiamente risolto su chi offre servizi di hosting, se poi le applicazioni
sono in housing, il pc lo setti come ti pare quindi...


 del millenio, non dovrebbe piů essere utilizzato in alcun server
LE DATE NON HANNO 2, 4, 8, 3.14 CIFRE!
Una data č una data.
Quello che vedi č una stringa.
Questo č il punto.
Che poi la tua app giri su un server americano, russo, giapponese, o su 
un client o su una lavastoviglie non te ne deve fregare 'na mazza.
E' chiaro adesso? :)
Ciao

 Ho capito benissimo il punto della discussione.
perdonami la franchezza: non hai capito per niente il punto della
discussione.


 risultava MM/dd/yy!!!
La chiave "MM/dd/yy" è assolutamente corretta e la potrai trovare in altri
mille PC.
Non puoi certo pensare di cambiare il registry dei pc dove vai a mettere il
software.
Sarebbe così, se non ci fosse soluzione. Ma, in realtà, esiste il modo di
gestire le date *indipendentemente* dalle impostazioni del pc o dell'utente,
per cui basta modificare il tuo codice per renderlo *universale*, e sei a
posto.
Tutto qua.
Ciao
Alberto

 ha scritto nel messaggio
news:c6l8f3$d8jo1$
1...@ID-222113.news.uni-berlin.de

Non conoscevo questa funzione prima d'ora. Ora premo F1 e ti faccio sapere.


 
No DateSerial??? Ahi ahi ahiiiii!
