VBscript Date() US data ipv NL

[IceOnFire]

Ik heb een erg raar probleempje met ASP/VBscript op het moment. Op een engelse versie van Windows NY 4 server UK draait een pagina'tje die dmv Date() de datum weergeeft. Deze verschijnt als m/d/yy ipv dd-MM-yyyy zoals ik hem graag zou zien. De internationale instellingen van NT staan echter op NL, niet UK...

Voor zover ik weet slaat NT dit soort info alleen op onder [HKLM]/USERS/.DEFAULT/Control Panel/International en [HKLM]/USERS/{hiereenandereuser} op dezelfde plek en nat. in [HKEY CURRENT USER] op eveneens dezelfde plaats. Op mijn testsystemen die Win2K NL en UK draaien werkt alles wél met de goede data, het registery exporteren vanuit Win2K en importeren in NT werkt wel maar heeft geen effect.

uiteraard al een hoop rondgezocht op i-net en google, maar ik kan niks specifiek over bijv. verschillen tussen NT4 en win2k op dit gebied. iemand misschien nog een suggestie om NT tóch in het gareel te krijgen?

(LCID's zijn overigens geen oplossing, a) het werkt niet en b) het moet anders kunnen)

[McMad]

Date() geeft een datum terug die impliciet naar een string wordt geconverteerd. Om te bepalen hoe de string eruit komt te zien kun je format(date,"dd-mm-yyyy") oid gebruiken.

[gorgi_19]

Of in een workaround zelf een eenvoudige functie hiervoor schrijven....

code:

Function ProperDate(Byval dtDate as Date) as String
    Dim returnDate as Date
    returnDate = Day(dtDate) & "-" & Month(dtDate) & "-" & Year(dtDate)"
    return returnDate
    
End function

edit:

Hmm.. Volgens mij ben ik weer lekker talen aan het mixen (leuk dat VB.Net em VBScript samen.. ) Maar het geeft wel een idee.

[IceOnFire]

thx so far, zeker die eerste is een vrij makkelijke variant van symptoombestrijding. maar toch, het moet ook "normaal" kunnen door de default ergens binnen Windows aan te passen en zo de oorzaak aan te pakken...

in W2K weet ik dat prima te vinden en de registersleutels bestaan ook in vrijwel ongewijzigd formaat in NT, maar dat lost het probleem dus niet op. zoeken in de registry naar strings als mm/dd/yy en aanverwanten levert overigens ook niets op.

waarom ik het persé bij de bron wil aanpakken? ik gebruik het op een behoorlijk aantal verschillende plaatsen om automatisch data van bepaalde zaken vast te leggen en veel aanpassen is nogal omslachtig. daarbij kan ik het niet uitstaan niet uit te kunnen vinden waar ie dat datumformaat toch vandaan haalt...

[_Thanatos_]

Volgens mij gaat deze draad over hetzelfde probleem

[IceOnFire]

dat draadje had ik al gevonden... zoals ik onderaan mijn eerste post al vermeld zijn LCID's niet de oplossing omdat ze o.a. bij mij tegen dit probleem überhaupt niet werken...

[Crazy D]

Is dat niet gewoon Control panel -> regional settings? (moet je uiteraard wel achter de computer kunnen schuiven ).

[Dennis van der Stelt]

Het zijn inderdaad de regional settings van diegene waarmee jij de boel aanstuurt/runt.

Wij hebben hier een aantal VB componenten welke worden aangeroepen door ASP. De componenten hangen in MTS en worden aangeroepen door een apart user-account door ons aangemaakt. De user-account moet wel de juiste regional settings hebben, anders zet hij de datum verkeerd neer.

Erg rot probleem.

[raptorix]

Lees eens wat over session.lcid

The LCID property uses the location identifier number to access information on display format issues, such as currency, date, and time, that are specific to a location or region. The location identifier number uniquely defines a geographic location or region. For example, the location identifier number for France is 1036.

http://www.devguru.com/Technologies/asp/quickref/session_lcid.html

[IceOnFire]

zoals ik al zei: ook LCID's werkten niet. ook met de NL'se LCID bleven de data amerikaans default, de franse bijvoorbeeld leverde wél het "goeie" resultaat op.

inmiddels heb ik het wel op weten te lossen, dus voor de search: als je via regional settings in het control panel de instellingen op amerikaans en meteen daarna op Nederlands zet, hem een aantal bestanden van de servercd laat kopieren (?) en reboot, dán zijn de data eindelijk in het goede formaat.

(misschien dat ik ervoor toch nog iets anders specifieks heb gedaan want volgens mij heb ik het bovenstaande zo'n beetje als eerste geprobeerd, al vroeg hij die keer niet om de NT server cd)