[MSSQL] Structurele oplossing datum/tijd

[Altaphista]

Steeds weer kom ik het tegen: ik ontwikkel een (web)applicatie m.b.v. MSSQL en ik maak gebruik van een datum (en tijd). Als het klaar is gaat het naar de klant en (zoals eigenlijk al verwacht) zijn er problemen met de datum (en de tijd) opvragen/converten/updaten. Ik heb dit nu drie keer meegemaakt, en iedere keer was de oplossing weer anders: de ene keer moet de datum van het formaat dd-mm-yyyy zijn en de andere keer mm/dd/yyyy.

Bestaat hier een structurele oplossing voor, of heeft iemand die al een keer grondig aangepakt? Het is nl. geen doen om je ontwikkelomgeving telkens te gaan aanpassen aan die van de klant (taalinstellingen, etc.).

[MissingDog]

Gebruik maken van unix timestamps in plaats van gewone datuminvoer, dan kan je het altijd laten displayen op basis van de lokaal ingestelde datumvoorkeuren.

[EfBe]

altijd yankee format gebruiken wanneer je datums in de sqlserver database gaat zetten en dus ook wanneer je ze eruit haalt. in je client kun je dan conversies plegen. SQLServer werkt verder intern met een eigen format, dus het is puur een client probleem: je moet zelf de conversie specificeren in je client hoe je van een datetime field in sqlserver format naar bv dd-mm-yyyy gaat.

[Verwijderd]

ik converteer mijn datum altijd in SQL en dan heb je geen problemen.
convert(varchar(20),@dteDate,103) bijvoorbeeld. (dit is geloof ik yy/mm/dd) en zo heb je nog meer formats.

[Bjorker]

MissingDog geeft mijns inziens het juiste antwoord. Gebruik unix-timestamps voor de opslag in de db. Invoer en uitvoer zijn eenvoudig en universeel aan te passen.

[Annie]

Unix timestamps? We hebben het hier over MS SQL Server, eventjes die oogkleppen afzetten

Back ontopic: gebruik de ISO 8601 notatie. Dat is het veiligst.

[ Voor 3% gewijzigd door Annie op 25-04-2003 21:10 . Reden: google tags ]

[EfBe]

Annie: die iso standaard is idd een goede suggestie, ik gebruik altijd mm/dd/yyyy, maar dat iso format is volgens mij beter, ik kende het echter niet, bedankt voor de info

[Batsies]

Ik convert me data's naar een vaste datum, dan heb ik nooit problemen, net zoals Dwergje al zegt, op MSDN is wat te vinden over convert: http://msdn.microsoft.com...qlce/htm/_lce_convert.asp

[KoeKk]

Of doe het gewoon in SQL:

SQL:

SET DATEFORMAT dmy

dan wel altijd ervoor zorgen dat je de datum/tijd als d/m/y in je dm probeerd te stoppen

Ik heb dit in mij database functie gestopt en krijg je dus het volgende:

ASP:

  Sub db_Open()
    Set db = Server.CreateObject("ADODB.Connection")
    db.Open init_DB
    db.Execute("SET DATEFORMAT dmy")
  End Sub 

[Altaphista]

okee, jullie hebben een aantal tips om zelf ervoor te zorgen dat je altijd met een bepaalde format werkt. Zelf ben ik er niet zo voor om steeds de format te gaan setten of de datum moet gaan converten omdat je dan alsnog tegen fouten kunt aanlopen bij verschillende databases en omdat je dan snel het overzicht kan verliezen.

Volgens mij is het ook het slimst om een timestamp ()/ISO-Notatie te gebruiken en gewoon altijd je uitvoer aan te passen aan hoe je het wilt hebben. Dit wordt sowieso geslikt door alle MSSQL servers en is het meest overzichtelijk, ook als anderen aanpassingen moeten maken in jouw code. Ik zal eens gaan kijken hoe ik dit kan gaan invoeren hier .

[EfBe]

Timestamp is in SQLServer een binary value, bedoeld voor het tracken van recordchanges. Het is dus geen date/time value zoals in Oracle

[DukeMan]

Ik gebruik meestal een eigen formaat. Op de client zet ik de huidige/in te voeren datum/tijd om naar altijd het volgende (string) formaat:
yyyymmddhhmmss (jaar/maand/dag/uur/minuut/seconde).
Dan heb je altijd het juiste formaat, ongeacht je database type/land instellingen.

Zelf nog even een routine maken die een datum in het bovenstaande formaat kan converteren, of eentje die bovenstaand formaat kan omzetten naar een weergave formaat en je kan dit altijd en overal toepassen.

Ik gebruik het al een tijdje en het is super makkelijk!!!

(Komt ook nog het voordeel bij dat je er makkelijk op kan sorteren om datum!)