[php] zet datum verkeerd om bij insert

[Rac-On]

Ik zit met een probleem en kon in de search helaas geen antwoord vinden.
Ik ben bezig met een webbased helpdeskapplicatie. Het idee is dat op een centrale server mailboxen worden geleegd en in de vorm van tickets opgeslagen in een SQL database.
Vervolgens is er een php frontend, waarbij de helpdeskmederwerkers vanaf iedere pc kunnen inloggen.

Nu kom ik een vervelend iets tegen. Gebruikers kunnen datums invoeren (bijvoorbeeld voor een terugbelafspraak). Nu wil het probleem dat een datum die is ingevoerd als yyyy-mm-dd soms in die vorm wordt opgeslagen en soms als yyyy-dd-mm. Ik heb het idee dat php hierbij rekening houdt met de landinstellingen van de computer waarop de gebruiker werkt?

Kent iemand dit probleem? En weet iemand hoe het op te lossen is? Kan je in de php configuratie niet aangeven dat datums altijd als een bepaald formaat worden verwacht?

[creative8500]

PHP houdt nooit rekening met de gebruiker.

[drm]

rac-on:
Kent iemand dit probleem? En weet iemand hoe het op te lossen is? Kan je in de php configuratie niet aangeven dat datums altijd als een bepaald formaat worden verwacht?

Gewoon aan de gebruikers vertellen in welk formaat ze het in moeten voeren, door bijvoorbeeld (yyyy-mm-dd) achter het veld te zetten, o.i.d.

[pjonk]

Werk je met een MySQL database?
Sla je de velden op als datatype DATE? In dit geval dient de datum altijd als yyyy-mm-dd opgegeven te worden.

MySQL manual:
The DATE type is used when you need only a date value, without a time part. MySQL
retrieves and displays DATE values in 'YYYY-MM-DD' format. The supported range is '1000-
01-01' to '9999-12-31'.

[ Voor 7% gewijzigd door pjonk op 30-12-2003 12:49 . Reden: foutje ]

[Altaphista]

1 tip: ga over op de ISO Notatie en bouw er zelf een tussenstap tussen, dan zit je altijd goed!
Ik heb dit 'probleem' ook eens gehad (zie: [rml][ MSSQL] Structurele oplossing datum/tijd[/rml] het is mssql, weet ik, maar het gaat om het idee erachter)

[whoami]

Je hoeft je geen zorgen te maken over hoe (in welke notatie) de datums in de DB gezet worden; als een Amerikaan jouw website bezoekt zal hij de datum in een andere notatie willen zien dan wanneer een Nederlander jouw website bezoekt.
Zorg er dus gewoon voor dat je je datums in het juiste (gewenste) formaat toont op je website (clientside).

[Rac-On]

drm schreef op 30 december 2003 @ 12:48:
[...]
Gewoon aan de gebruikers vertellen in welk formaat ze het in moeten voeren, door bijvoorbeeld (yyyy-mm-dd) achter het veld te zetten, o.i.d.

nee dat lost dus helaas het probleem niet op. Het vage is dat als ik als waarde invoer: 2003-12-10, dat bij het weergeven van het veld dit wordt vertaald naar oct 12 2003.
Als ik vervolgens in de database kijk, zie ik ook dat mijn datum is opgeslagen als 2003-10-12.

Ik heb de scripts (ik gebruik codecharge voor de groffe opzet) nagekeken, maar er gebeurd niks vreemds met de datum. Het enige wat ik me voor kan stellen, is dat de SQL server en de server waarop de PHP draait, een andere landinstelling heeft, en dat daarom de dataum veranderd wordt.
zelfs als ik in de query analizer intype;

code:

update voicefinders SET cfgdate='2003-12-10 12:14:00' where id = 133519

wisseld hij de 12 en de 10 om....

[whoami]

Gebruik je nu SQL Server of MySQL?

In ieder geval kan je eens nagaan of je in PHP parametrized queries kunt gebruiken (en zoja: hoe je die dan schrijft).

[Altaphista]

Nogmaals, check mijn reply boven (is echt DE oplossing voor mij geworden) en neem ook reply 1 van whoami ter harte! (anders blijf je aan het prutsen, de taalinstellingen op de server hoeven maar te wijzigen en je bent terug bij af)

Dus maak het een varchar(25), sla op als YYYY-MM-DDThh:mm:ss.sTZD en bouw twee functies, setDatum(string) {set isodatum formaat} en getDatum() {ret: gewenst formaat}

[ Voor 17% gewijzigd door Altaphista op 30-12-2003 13:39 . Reden: argumentatie toegevoegd ]

[whoami]

Altaphista schreef op 30 december 2003 @ 13:37:
Dus maak het een varchar(25), sla op als YYYY-MM-DDThh:mm:ss.sTZD en bouw twee functies, setDatum(string) {set isodatum formaat} en getDatum() {ret: gewenst formaat}

Waarom zou je dat doen? Een datum sla je op in een date-veld, niet in een varchar veld.
Als je het opslaat in een VARCHAR, dan ga je vroeg of laat in de problemen komen. (Stel bv. dat je de records wilt ophalen waarvoor de maand van die datum december is).

[Altaphista]

whoami schreef op 30 december 2003 @ 13:39:
[...]


Waarom zou je dat doen? Een datum sla je op in een date-veld, niet in een varchar veld.
Als je het opslaat in een VARCHAR, dan ga je vroeg of laat in de problemen komen. (Stel bv. dat je de records wilt ophalen waarvoor de maand van die datum december is).

ik snap het ja, maar ik heb ook het probleem gehad dat van server (met andere collation en taalinstellingen) is gewisseld: bij het transformeren van data van de ene naar de andere wordt (f.e.) 2003-01-10 dan 2003-10-1 dus dan doet de query voor december het ook niet. En je script requests werken niet meer op dezelfde manier. (wordt de ene keer wel omgewisseld, andere keer niet) Of je hebt een sql query waar het e.e.a. vanzelf wordt omgedraaid voor je...

[Verwijderd]

Check in welk formaat de db die je gebruikt een datum lekker vind en zorg dat hij in het goede formaat wordt opgeslagen.
Ik heb converteer zelf altijd handmatig de datum voordat ik hem opsla en toon aan de database.
Mysql vindt: 2003-10-10 leuk en de eindgebruikter 10-10-2003.
tis ff meer werk, maarja life's a bitch aint it

[whoami]

Altaphista schreef op 30 december 2003 @ 13:45:
[...]

ik snap het ja, maar ik heb ook het probleem gehad dat van server (met andere collation en taalinstellingen) is gewisseld: bij het transformeren van data van de ene naar de andere wordt (f.e.) 2003-01-10 dan 2003-10-1 dus dan doet de query voor december het ook niet. En je script requests werken niet meer op dezelfde manier. (wordt de ene keer wel omgewisseld, andere keer niet) Of je hebt een sql query waar het e.e.a. vanzelf wordt omgedraaid voor je...

2 woorden: parametrized queries.
De vraag is alleen of PHP dat mogelijk maakt.

[drm]

whoami:
2 woorden: parametrized queries.
De vraag is alleen of PHP dat mogelijk maakt.

Nope, dat gaat niet werken in PHP. Als je dat wilt zul je het zelf moeten bouwen. En dat komt op hetzelfde neer als wat IceFlame ook zegt.

[Rac-On]

Altaphista schreef op 30 december 2003 @ 13:45:
[...]

ik snap het ja, maar ik heb ook het probleem gehad dat van server (met andere collation en taalinstellingen) is gewisseld: bij het transformeren van data van de ene naar de andere wordt (f.e.) 2003-01-10 dan 2003-10-1 dus dan doet de query voor december het ook niet. En je script requests werken niet meer op dezelfde manier. (wordt de ene keer wel omgewisseld, andere keer niet) Of je hebt een sql query waar het e.e.a. vanzelf wordt omgedraaid voor je...

Precies mijn puntje. Ik wil de datum niet voor niks als datum opslaan. Anders had ik er overal wel een timestamp o.i.d. in geramt. Ik wil ook de (SQL) date en time functies gebruiken. Vooral voor het optellen en aftrekken van de datums.

Het probleem waar ik mee zit beschrijf je precies:

wordt de ene keer wel omgewisseld, andere keer niet

Misschien moet ik mijn vraag dus duidelijker stellen:
Weet iemand waarom en wanneer die datums omgedraaid worden en hoe ik dit voorkom?

@drm: Het probleem is dus niet zozeer hoe ik het aan de gebruiker toon, daar kan ik makkelijk een formaat meegeven. Het probleem is dat mijn datums niet worden opgeslagen zoals verwacht, en dat ik de indruk heb dat het ook afhangt op welke van mijn servers ik het script draai. Daarom heb ik het vermoeden dat php hierbij gebruik maakt van de landinstellingen van de betreffende server (of dat er een conversie plaatsvind in het sql gedeelte).. Ik kan me voorstellen dat je ergens in de config kunt aangeven dat php (of de sql server) een datum op een bepaalde manier moet aanvaarden en versturen...

[ Voor 22% gewijzigd door Rac-On op 30-12-2003 14:04 ]

[Anders]

rac-on schreef op 30 december 2003 @ 14:00:
Misschien moet ik mijn vraag dus duidelijker stellen:
Weet iemand waarom en wanneer die datums omgedraaid worden en hoe ik dit voorkom?

MySQL gaat uit van YYYY-MM-DD format. Als jij een YYYY-DD-MM datum doorgeeft, of DD-MM-YYYY, zal MySQL proberen die zelf naar YYYY-MM-DD te converteren.

Geef je 20-10-2003 (20 januari 2003) door, dan zal MySQL "snappen" dat die 20 de dag betreft, en de datum opslaan als 2003-10-20 in een DATE-veld. Geef je echter 08-10-2003 (bedoeling: 8 januari 2003) door, dan zal MySQL dat interpreteren als MM-DD-YYYY en het opslaan als 2003-08-10 (oftewel: 10 augustus 2003).

Ik heb daar tijden geleden veel gedonder mee gehad, en voor de zekerheid converteer ik data vooraf steevast naar YYYY-MM-DD format voordat ik ze in een DATE-veld plaats. Sindsdien nooit meer problemen gehad.

Echter, als ik jouw voorbeeld zie (dat 2003-12-10 als 2003-10-12 in de database wordt geplaatst) gaat ook dat niet meer op. Geef je die datum gewoon als string op (INSERT INTO table SET datum = '2003-12-10')?

[Rac-On]

Anders:
lezen alsjeblieft. Als ik letterlijk invoer in een sql query:

code:

update voicefinders SET cfgdate='2003-12-10 12:14:00' where id = 133519

Dan converteerd de sql server dit naar 2003-10-12. Hij vind dus blijkbaar dat mijn invoer van het yyyy-dd-mm formaat is, en converteerd dit naar yyyy-mm-dd formaat. Terwijl ik het toch echt in het juiste formaat aanlever......

Ik vind het ook erg vreemd, en heb het vermoeden dat mijn collega iets vreemds met de instellingen van de SQL server heeft gedaan. Vandaar de vraag of iemand weet of dat een instelling is, en zo ja, welke....

[Grijze Vos]

Als ik gebruikers data laat invoeren gebruik ik drie select boxes, 1 voor dag, maand en jaar, en vorm dat zelf om tot de juiste datum. Hoe die insert scheef kan lopen vraag ik me af, want dat zou gewoon moeten werken.

[LuCarD]

rac-on schreef op 30 december 2003 @ 15:45:
Anders:
lezen alsjeblieft. Als ik letterlijk invoer in een sql query:

code:

update voicefinders SET cfgdate='2003-12-10 12:14:00' where id = 133519

Dan converteerd de sql server dit naar 2003-10-12. Hij vind dus blijkbaar dat mijn invoer van het yyyy-dd-mm formaat is, en converteerd dit naar yyyy-mm-dd formaat. Terwijl ik het toch echt in het juiste formaat aanlever......

Ik vind het ook erg vreemd, en heb het vermoeden dat mijn collega iets vreemds met de instellingen van de SQL server heeft gedaan. Vandaar de vraag of iemand weet of dat een instelling is, en zo ja, welke....

Misschien ben ik kippig maar ik zie nog nergens waar je ons verteld welke db je gebruikt.....

Voor MySQL is dit een (de enige) correcte notatie voor datums. Andere database's reageren anders......
Vertel dan gelijk ook even welk OS en versie nummer van de database. Eventueel SP's etc....

Maar volgens mij gebruik je MS SQL Server. En volgens mij neemt die de datum notatie over van de server "regional options" in het control panel...

[Rac-On]

sorry mijn fout. het is helaas een microsoft sql server, die draait op een nt machine. De preciese details kan ik je zo snel niet geven, ivm beperkte rechten...

Ik had idd het vermoeden dat het te maken heeft met de landinstellingen, maar is er geen manier om deze te omzeilen en sql specifiek aan te geven welke instellingen hij moet gebruiken?

[LuCarD]

rac-on schreef op 30 december 2003 @ 16:21:
sorry mijn fout. het is helaas een microsoft sql server, die draait op een nt machine. De preciese details kan ik je zo snel niet geven, ivm beperkte rechten...

Ik had idd het vermoeden dat het te maken heeft met de landinstellingen, maar is er geen manier om deze te omzeilen en sql specifiek aan te geven welke instellingen hij moet gebruiken?

[rml]KoeKk in "[ MSSQL] Structurele oplossing datum/tijd"[/rml]

Zoals Altaphista hierboven al vermeld....!

[Rac-On]

ok, het probleem op de windows machine is intussen opgelost. Een beetje spelen met de regiosetting van alle betrokken machines heeft het probleem opgelost.

Nu doet zich echter het tweede probleem voor, de linux proxy's waar een aantal MySQL databases op draaien, hebben geen configuratiescherm/regiosettings. Duzz ook geen tabje waar ik het date format in kan stellen.. iemand enig idee hoe het wel kan?

[LuCarD]

MySQL heeft dit probleem niet.... deze heeft geen regio ondersteuning....

Alle datum formaten zijn yyyy-mm-dd

zie http://www.mysql.com/docu...ter/index.html#Using_DATE

[djluc]

Misschien heb je hier wel iets aan: http://www.phpfreakz.nl/library.php?sid=12096