corsa91 Skrevet 2. april 2013 Del Skrevet 2. april 2013 Jeg har en database som viser datoer i yyyy-mm-dd. Jeg vil heller ha den som dd-mm-yyyy. Har lest på nettet at jeg må legge til dette etter SELECT DATE_FORMAT(column_name, '%d/%m/%Y') Men det fungerer ikke. Lenke til kommentar
process Skrevet 2. april 2013 Del Skrevet 2. april 2013 (endret) Fordelen med å lagre i yyyy-mm-dd er at du kan sortere numerisk etter dato. Det kan være nyttig i mange tilfeller hvis du vil ha ting kronologisk og kan derfor være fornuftig i en database. Visningen av data kan derimot være greit å endre på for lesbarhet. Hva slags database? Er det viktig at det lagres i databasen i dette formatet? Bruker du SELECT DATE_FORMAT en spørring? Kan du heller endre visning i front end? Kan du vise ett eksempel på hva du har gjort og hva du forsøker å gjøre? Endret 2. april 2013 av process Lenke til kommentar
GeirGrusom Skrevet 3. april 2013 Del Skrevet 3. april 2013 (endret) yyyy-mm-dd følger ISO 8601. Det er ikke spesielt lurt å gå bort fra dette. Hvorfor skrive det på denne måten? Som nevnt over så gjør dette at verdien vil faktisk la seg sortere som en tekstverdi, og dessuten starter alle tall med det mest signifikante verdien på venstre, ikke på høyre. Endret 3. april 2013 av GeirGrusom Lenke til kommentar
corsa91 Skrevet 3. april 2013 Forfatter Del Skrevet 3. april 2013 Jeg har lagt ved bilde av hvordan den ser ut nå og hvordan jeg ønsker. Det er MYSQL database. Jeg vet ikke om det er mulig å endre front end visning siden jeg ikke vet hvordan. Bruker Xampp akkurat nå. Fordelen med å lagre i yyyy-mm-dd er at du kan sortere numerisk etter dato. Det kan være nyttig i mange tilfeller hvis du vil ha ting kronologisk og kan derfor være fornuftig i en database. Visningen av data kan derimot være greit å endre på for lesbarhet. Hva slags database? Er det viktig at det lagres i databasen i dette formatet? Bruker du SELECT DATE_FORMAT en spørring? Kan du heller endre visning i front end? Kan du vise ett eksempel på hva du har gjort og hva du forsøker å gjøre? Lenke til kommentar
GeirGrusom Skrevet 3. april 2013 Del Skrevet 3. april 2013 (endret) Du burde ikke gjøre dette i SQL. Det er utrolig dårlig skikk å ha noen som helst forhold til presentasjon eller logikk i databasen. date("d-m-Y", theDate) ref Men spør du meg er det ikke hverken nødvendig eller en spesielt god idé. Utviklere generelt synes datoer er et helvete å behandle, og grunnen til det er at alle mulige folk har så mange gode idéer om hvordan datoer skal presenteres. Hvis alle bare holdt seg til den fornuftige og veletablerte ISO standarden for tidsrepresentasjon så hadde datoer skapt langt mindre problemer enn det faktisk gjør. edit: det man også kommer borti ved å snu det rundt, er at visse datoer er tvetydige med den radikalt idiotiske måten hvor datoer presenteres i USA (mm-dd-yyyy). Ettersom ISO-en setter året først, som er det fornuftige, så er dette ikke et problem ettersom det ikke er noen systemer med yyyy-dd-mm som er i bruk av noen. Dermed er ikke datoen tvetydig. Endret 3. april 2013 av GeirGrusom Lenke til kommentar
MailMan13 Skrevet 3. april 2013 Del Skrevet 3. april 2013 (endret) Interessant på en del microsoft-produkter. Ex. på officeprodukter med amerikansk-engelsk oppsett vil 12-04-2013 bety 4. desember samtidig som 13-04-2013 gir 13. april (!) ISO formatet er desverre ikke sikkert heller. På SQLServer godtas ISO formatet ved siden av lokalisert med engelsk eller nordiske locales, men... SET LANGUAGE FRENCH; select convert(datetime, '2013-04-13') Msg 242, Level 16, State 3, Line 1 La conversion d'un type de données CHAR en type DATETIME a donné une valeur hors limite de date et d'heure. So...yeah... Men bruk ISO så langt som mulig ja (eller bruke en ORM og la den ordne det...), la presentasjonslaget ta formateringen! Endret 3. april 2013 av MailMan13 Lenke til kommentar
corsa91 Skrevet 3. april 2013 Forfatter Del Skrevet 3. april 2013 (endret) Du referer til denne koden som jeg kan bruke men hvor skal jeg plassere den? date("d-m-Y", theDate) Og er jeg nødt til å bruke det på alle sidene? Hvordan ser det ut hvis jeg går inn på phpmyadmin sidne da? Du burde ikke gjøre dette i SQL. Det er utrolig dårlig skikk å ha noen som helst forhold til presentasjon eller logikk i databasen. date("d-m-Y", theDate) ref Men spør du meg er det ikke hverken nødvendig eller en spesielt god idé. Utviklere generelt synes datoer er et helvete å behandle, og grunnen til det er at alle mulige folk har så mange gode idéer om hvordan datoer skal presenteres. Hvis alle bare holdt seg til den fornuftige og veletablerte ISO standarden for tidsrepresentasjon så hadde datoer skapt langt mindre problemer enn det faktisk gjør. edit: det man også kommer borti ved å snu det rundt, er at visse datoer er tvetydige med den radikalt idiotiske måten hvor datoer presenteres i USA (mm-dd-yyyy). Ettersom ISO-en setter året først, som er det fornuftige, så er dette ikke et problem ettersom det ikke er noen systemer med yyyy-dd-mm som er i bruk av noen. Dermed er ikke datoen tvetydig. Endret 3. april 2013 av corsa91 Lenke til kommentar
GeirGrusom Skrevet 3. april 2013 Del Skrevet 3. april 2013 Et eller annet sted presenterer du datoen. Det er her du må endre det, ikke i selve databasemotoren. Lenke til kommentar
corsa91 Skrevet 3. april 2013 Forfatter Del Skrevet 3. april 2013 (endret) Her ser du det den delen av koden <table border="1"> <tr><td>Fagkode</td><td>Fagnavn</td><td>Tittel</td><td>Dato</td><td>Tid</td></tr> <?php include 'include/db_connect.php'; $sql= "select * FROM deadline ORDER BY Date" ; $resultat=mysql_query($sql); $antall=mysql_num_rows($resultat); for ($i=0; $i <$antall; $i++){ $rad=mysql_fetch_row($resultat); echo '</td><td>'; echo $rad[1]; echo '</td><td>'; echo $rad[2]; echo '</td><td>'; echo $rad[3]; echo '</td><td>'; echo $rad[4]; echo '</td><td>'; echo $rad[5]; echo '</td></tr>'; } ?> skal jeg plassere i echo $rad[5]; ? Endret 3. april 2013 av corsa91 Lenke til kommentar
process Skrevet 3. april 2013 Del Skrevet 3. april 2013 echo date("d-m-Y", $rad[5]); Dersom overnevnte funksjon er korrekt. Lenke til kommentar
corsa91 Skrevet 3. april 2013 Forfatter Del Skrevet 3. april 2013 (endret) Notice: A non well formed numeric value encountered in C:\Program Files (x86)\xampp\htdocs\test\listallefrister.php on line 24 01-01-1970 er eneste jeg får opp når jeg skriver dette: echo date("d-m-Y", $rad[5]); Endret 3. april 2013 av corsa91 Lenke til kommentar
quantum Skrevet 3. april 2013 Del Skrevet 3. april 2013 Hvis alle bare holdt seg til den fornuftige og veletablerte ISO standarden for tidsrepresentasjon så hadde datoer skapt langt mindre problemer enn det faktisk gjør. Inntil verden har blitt enig med seg selv om et felles datoformat er det kanskje like greit med datopresentasjon ihht. locale ... Lenke til kommentar
quantum Skrevet 3. april 2013 Del Skrevet 3. april 2013 Sett opp databasen med riktig locale-support, se http://dev.mysql.com/doc/refman/5.0/en/locale-support.html Formatering av datoer, tall osv skjer gjerne i guikode uansett, men er ikke databasen satt opp riktig blir dessuten sortering feil, og det er noe som gjerne kan overlates til databasemotoren. Vi vil jo f.eks. gjerne at den sorterer norske tegn riktig. http://dev.mysql.com/doc/refman/5.0/en/charset-applications.html Lenke til kommentar
GeirGrusom Skrevet 4. april 2013 Del Skrevet 4. april 2013 Sett opp databasen med riktig locale-support, se http://dev.mysql.com...le-support.html Formatering av datoer, tall osv skjer gjerne i guikode uansett, men er ikke databasen satt opp riktig blir dessuten sortering feil, og det er noe som gjerne kan overlates til databasemotoren. Vi vil jo f.eks. gjerne at den sorterer norske tegn riktig. http://dev.mysql.com...plications.html For å sortere tekst riktig bruker du unicode collation. Lokalisering i databasen bør ikke påvirke oppførselen til programmet. Lenke til kommentar
quantum Skrevet 4. april 2013 Del Skrevet 4. april 2013 For å sortere tekst riktig bruker du unicode collation. Lokalisering i databasen bør ikke påvirke oppførselen til programmet. Hvis man har opprettet en database med unicode tegnsett. Aner ikke hva som er standard i mysql. Lokaliseringen påvirker oppførselen til databasen, som jeg oppfattet at spørsmålet dreier seg om. Hvis det var spørsmål om hvordan man skal få php til å presentere datoer på ønsket måte så må man titte oppover i stacken ja ... PS, TS må jo gjerne prøve å forklare akkurat hva han ikke forstår også, så kanskje det går an å komme med et ordentlig svar ... :o) Lenke til kommentar
GeirGrusom Skrevet 4. april 2013 Del Skrevet 4. april 2013 Hvis man har opprettet en database med unicode tegnsett. Aner ikke hva som er standard i mysql. Lokaliseringen påvirker oppførselen til databasen, som jeg oppfattet at spørsmålet dreier seg om. Hvis det var spørsmål om hvordan man skal få php til å presentere datoer på ønsket måte så må man titte oppover i stacken ja ... PS, TS må jo gjerne prøve å forklare akkurat hva han ikke forstår også, så kanskje det går an å komme med et ordentlig svar ... :o) ^____________________^ Lenke til kommentar
quantum Skrevet 4. april 2013 Del Skrevet 4. april 2013 (endret) kryptisk, kryptisk ... Spørsmål til TS: Hvordan har du deklarert tabellen din? Er datoen du vil vise et char-felt eller et datofelt? Databaser pleier å lagre datoer, timestamps etc. som ett eneste stort tall som representerer antall millisekunder siden 1.1.1970 i en gitt tidssone, og så er det opp til andre parametre å styre hvorledes det presenteres. Når datoen sendes opp til php er det fortsatt uten noen form for "presentasjon", det skjer da i php ved hjelp av f.eks. date-funksjonen. Men dersom det ikke er en dato i form av et tall, men isteden en char-verdi (dvs. streng i php-land) inneholdende en formatert datostreng, så blir jo date-funksjonen til php hjelpeløs, for den forventer jo et tall (antall millis). "Feilmeldingen" du får - "A non well formed numeric value encountered" kan tyde på at dette er problemet. Edit: Kan du bruke gettype til å se hvaslags type du egentlig har datoen i? http://php.net/manua...ion.gettype.php Edit2: Problemet med bruk av DATE_FORMAT i sql tyder også på at datoen din ikke er lagret i et datofelt i databasen. Hvis du hadde postet feilmeldingen også hadde problemet antagelig vært løst for lengst. Endret 4. april 2013 av quantum Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå