Gå til innhold

Anbefalte innlegg

Videoannonse
Annonse

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 av process
Lenke til kommentar

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 av GeirGrusom
Lenke til kommentar

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?

post-185298-0-63927800-1364983282_thumb.png

Lenke til kommentar

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 av GeirGrusom
Lenke til kommentar

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 av MailMan13
Lenke til kommentar

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 av corsa91
Lenke til kommentar

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 av corsa91
Lenke til kommentar

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 av corsa91
Lenke til kommentar

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

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

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

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

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

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 av quantum
Lenke til kommentar

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 konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...