mboost-dp1
"Kalender"tabel
#41
Mit forslag:
Mit forslag:
<?php
// old PHP
function findweekdate($y, $w, $d) {
$target = $y . ' ' . $w . ' ' . $d;
$t = mktime(0, 0, 0, 1, 29, $y-1);
while(date('o W N', $t) != $target) {
$t += (24*60*60);
}
return $t;
}
$res = findweekdate(2009, 33, 1);
echo date('d/m/Y', $res) . "\r\n";
// PHP 5.2+
$dt = new DateTime();
$dt->setISODate(2009, 33, 1);
echo $dt->format('d/m/Y') . "\r\n";
?>
Ooh, så PHP *har* fået et DateTime API. Så må jeg undskylde for de tidligere udsagn :)
http://dk2.php.net/manual/en/datetime.construct.ph...
Og den ser sørme ud til at benytte en DATETIME string som construct, ikke unixtime :D
http://dk2.php.net/manual/en/datetime.construct.ph...
Og den ser sørme ud til at benytte en DATETIME string som construct, ikke unixtime :D
fidomuh (46) skrev:
Det giver bare ikke nogen mening for mig at bruge noget andet end unixtime til timestamps, da det ( imo ) er vaesentligt nemmere at arbejde med.
Du bliver altså nødsaget til at forklare mig, hvad du mener, at fordelen ved Unix time - for dig - er.
Jeg er helt med på, at der kan være en fordel for databasen i at bruge det som bagvedliggende format, men det er noget helt andet. Det er ikke noget, du skal tage dig af.
Du nævner også selv, at du skal konvertere til en rigtig dato, hvis den skal præsenteres, så hvorfor giver det nogensinde mening for dig at have datoen i et andet format, som du ikke kan læse direkte?
Jeg vil også meget gerne vide, hvordan det er meget lettere for dig med Unix time at finde et ugenummer, end det er med en mere OO-baseret repræsentation af en dato.
#59
Kort sagt, at det er ufatteligt meget nemmere at traekke tid fra og til.
Jeg laver ellers det hele her, og hvis Unixtime er hvad der ligger i databasen, hvorfor saa ikke bare arbejde med det?
Ja, selvfoelgelig.
090101014055 <-- er ogsaa rimeligt fucking ubrugeligt for klienterne.
Hvornaar har jeg brug for at laese det direkte?
Hvordan faar jeg, i PHP, ugenummeret ud af DATETIME eller TIMESTAMP?
Med unixtime skriver jeg date("w",[time]).
Og i unix/shell goer jeg, sjovt nok, det samme.
Jeg ser ikke nogen grund til IKKE at bruge Unixtime naar det alligevel er hvad jeg gemmer i databasen.
Saa man kan sige at det er nemmere, fordi det er nemmere at laegge tid fra og til - og det er typisk det jeg bruger mest.
Du bliver altså nødsaget til at forklare mig, hvad du mener, at fordelen ved Unix time - for dig - er.
Kort sagt, at det er ufatteligt meget nemmere at traekke tid fra og til.
Jeg er helt med på, at der kan være en fordel for databasen i at bruge det som bagvedliggende format, men det er noget helt andet. Det er ikke noget, du skal tage dig af.
Jeg laver ellers det hele her, og hvis Unixtime er hvad der ligger i databasen, hvorfor saa ikke bare arbejde med det?
Du nævner også selv, at du skal konvertere til en rigtig dato, hvis den skal præsenteres
Ja, selvfoelgelig.
090101014055 <-- er ogsaa rimeligt fucking ubrugeligt for klienterne.
så hvorfor giver det nogensinde mening for dig at have datoen i et andet format, som du ikke kan læse direkte?
Hvornaar har jeg brug for at laese det direkte?
Jeg vil også meget gerne vide, hvordan det er meget lettere for dig med Unix time at finde et ugenummer, end det er med en mere OO-baseret repræsentation af en dato.
Hvordan faar jeg, i PHP, ugenummeret ud af DATETIME eller TIMESTAMP?
Med unixtime skriver jeg date("w",[time]).
Og i unix/shell goer jeg, sjovt nok, det samme.
Jeg ser ikke nogen grund til IKKE at bruge Unixtime naar det alligevel er hvad jeg gemmer i databasen.
Saa man kan sige at det er nemmere, fordi det er nemmere at laegge tid fra og til - og det er typisk det jeg bruger mest.
Hvor tit er det lige man gør det?fidomuh (60) skrev:Kort sagt, at det er ufatteligt meget nemmere at traekke tid fra og til.
Jeg synes stadig du skal prøve at genskrive koden fra #3 , tilpasset whatever SQL din favoridt DB kører, med UNIXTIME istedet for DATE eller DATETIME.
At generere et timestamp der ikke refferere til et tidspunkt der slutter med hh:mm:ss er en halv umulighed.
Og indtil videre har du nægtet at tage stilling til andet end præsentation, noget der altid er nemt.
I C# skriver jeg .ToString("w"); og så er den klat ude af verden. (Eller string.Format("{0:w}", myDate); ). Præsentation er ligegyldigt, vi snakker altså om data!
Og vi har jo bevist flere gange at dine muligheder direkte på databasen er meget begrænsende med unixtime. Du kan ikke validere om en dato er invalid med det blotte øje, og du skal skrive unødvendig meget kode for at foretage dig det samme som med DATETIME.
Shell kommandoer er nok så irrelevant i forhold til programmering som det kan blive. De er et nærmest modsat paradigm.
#61
*kigger i samtlige shell scripts og php dokumenter*
... Altid?
Jojo, det synes jeg ogsaa .NET og ASP er, men derfor svarer jeg stadig paa hvad JEG bruger det til og hvorfor JEG foretraekker det.
Hvor tit er det lige man gør det?
*kigger i samtlige shell scripts og php dokumenter*
... Altid?
Shell kommandoer er nok så irrelevant i forhold til programmering som det kan blive. De er et nærmest modsat paradigm.
Jojo, det synes jeg ogsaa .NET og ASP er, men derfor svarer jeg stadig paa hvad JEG bruger det til og hvorfor JEG foretraekker det.
Det er ikke så tit jeg skal "bare" lave simple matematik, og udover det har vi jo vist at et full OO representation er simplere.fidomuh (62) skrev:*kigger i samtlige shell scripts og php dokumenter*
Derudover sammenlign:
time = 1249249912 + 86400;
time = DateTime.Now.AddDays(1);
Det er rimelig åbenlyst hvilket kode er nemmest at læse, nemmest at huske, og nemmest at maintaine.
#63
Sigh, du tvinger mig jo til at grave kode frem :)
Men eh:
time = time(++1d);
[add]
SKal lige siges at dette er en funktion i date, egentligt, som behandler unixtime.
Ellers vil det jo blot vaere time+86400, som ganske vist ikke er saa nemt at arbejde med ud fra det blotte oeje, men jeg har nu altid brugt samme funktionsframework ( min egen samling ) som godtager fx myTime(+1d).
[/add]
vs
time = DateTime.Now.AddDays(1);
Jeg er helt med paa hvad der er nemmest, er forskellen ikke blot hvordan API'et haandterer det?
Altsaa, helt basalt saa skal man jo i 99.9999% af tilfaeldene have dataene koert igennem en process, saa om man bruger unixtime eller OO er dybest set ligegyldigt.
Jeg foretraekker unixtime, fordi jeg saa kan behandle det som normale integers :)
Saa kan jeg fx tjekke om A er tidligere end B:
If($A<$B){
echo "Yespls.";
};
Jeg synes personligt bare at det er nemmere at arbejde med i nogle tilfaelde, og de tilfaelde hvor det ikke er nemmere, foeler jeg at det er det samme :)
Sigh, du tvinger mig jo til at grave kode frem :)
Men eh:
time = time(++1d);
[add]
SKal lige siges at dette er en funktion i date, egentligt, som behandler unixtime.
Ellers vil det jo blot vaere time+86400, som ganske vist ikke er saa nemt at arbejde med ud fra det blotte oeje, men jeg har nu altid brugt samme funktionsframework ( min egen samling ) som godtager fx myTime(+1d).
[/add]
vs
time = DateTime.Now.AddDays(1);
Jeg er helt med paa hvad der er nemmest, er forskellen ikke blot hvordan API'et haandterer det?
Altsaa, helt basalt saa skal man jo i 99.9999% af tilfaeldene have dataene koert igennem en process, saa om man bruger unixtime eller OO er dybest set ligegyldigt.
Jeg foretraekker unixtime, fordi jeg saa kan behandle det som normale integers :)
Saa kan jeg fx tjekke om A er tidligere end B:
If($A<$B){
echo "Yespls.";
};
Jeg synes personligt bare at det er nemmere at arbejde med i nogle tilfaelde, og de tilfaelde hvor det ikke er nemmere, foeler jeg at det er det samme :)
< > = operators er også defineret for DateTime i C# ;-)fidomuh (64) skrev:
Saa kan jeg fx tjekke om A er tidligere end B:
If($A<$B){
echo "Yespls.";
};
Men det handler mere om abstraktionsniveau, og data-integritet, ting som ikke rigtig virker relevant på det niveau du programmere på.
Men hvis jeg skulle designe et kæmpe system, vil jeg nok ikke benytte unixtime. Jo flere operationer der kan klares i ren SQL, destro mere kan du flytte workload som det passer dig.
Funktioner som:myplacedk (66) skrev:Men det kommer jo nok an på hvad du mener med "ren SQL".
DAY, MONTH, WEEK, YEAR, DATEADD, DATE_FORMAT, DATEDIFF osv. er bygget på DATE og DATETIME, ikke integer værdier.
Samt det at bygge CONSTRAINTS (validering).
Og tidligere emner som vi har nævnt er tidszoner, skudår, milisekunder. Listen fortsætter derudaf.
#65
Det er sandt.
Hvis jeg skulle strikke et kaempe system sammen ville jeg klart revurdere min egen praeference, men jeg ville goere det for hvert system.
Hvis man vender den om, saa er det jo rent faktisk blot et spoergsmaal om hvor man oensker at lave omregningen:
I dit "klient-til-sql" system, eller i SQL systemet.
Husk at du med DATEADD ( fx ) stadig omregner paa en eller anden maade.
Og i dette tilfaelde ville jeg vaelge udfra performance :)
Data "integritet" har, imo, ikke noget at goere med at vaelge DATETIME fremfor UNIXTIME.
Det er sandt.
Hvis jeg skulle strikke et kaempe system sammen ville jeg klart revurdere min egen praeference, men jeg ville goere det for hvert system.
Hvis man vender den om, saa er det jo rent faktisk blot et spoergsmaal om hvor man oensker at lave omregningen:
I dit "klient-til-sql" system, eller i SQL systemet.
Husk at du med DATEADD ( fx ) stadig omregner paa en eller anden maade.
Og i dette tilfaelde ville jeg vaelge udfra performance :)
Data "integritet" har, imo, ikke noget at goere med at vaelge DATETIME fremfor UNIXTIME.
Umidbart er mit gæt at der reelt ikke er et performance tab. Og jeg tror at DATEADD er mere optimiseret end "+ 86400".fidomuh (68) skrev:Husk at du med DATEADD ( fx ) stadig omregner paa en eller anden maade. Og i dette tilfaelde ville jeg vaelge udfra performance :)
Hvis du skal expose til en webservice, eller flytte dataen mellem forskellige systemer, så er der!fidomuh (68) skrev:Data "integritet" har, imo, ikke noget at goere med at vaelge DATETIME fremfor UNIXTIME.
Umidbart arbejder jeg kun med MS SQL og MySQL, og begge's API er bygget på DATETIME.myplacedk (70) skrev:Jaja, men i hvert fald nogle DBMS'er kan konvertere. Spørgmålet er om det er "rent" nok til dig.
Self. kan de konvertere, men hvorfor konvertere i SQL, OG business logic?
#51
Og så anden forbedrede udgave:
Og så anden forbedrede udgave:
<?php
// traditional (any PHP)
putenv('TZ=Europe/Copenhagen');
function findweekdate1($y, $w, $d) {
$target = "$y $w $d";
$t = mktime(12, 0, 0, 12, 29, $y-1);
$t += (($w - 1)*7*24*60*60);
for($i = 0; $i < 14; $i++) {
if(date('o W N', $t) == $target) {
return $t;
}
$t += (24*60*60);
}
return 0;
}
$res = findweekdate1(2009, 33, 1);
echo date('d/m/Y', $res) . "\r\n";
$res = findweekdate1(2009, 63, 1);
echo date('d/m/Y', $res) . "\r\n";
// OOP (PHP 5.2+)
date_default_timezone_set('Europe/Copenhagen');
$dt = new DateTime();
$dt->setISODate(2009, 33, 1);
echo $dt->format('d/m/Y') . "\r\n";
$dt->setISODate(2009, 63, 1);
echo $dt->format('d/m/Y') . "\r\n";
// alternative (newer PHP, possible 5.1+)
date_default_timezone_set('Europe/Copenhagen');
function findweekdate2($y, $w, $d) {
return strtotime("$y-W$w-$d");
}
$res = findweekdate2(2009, 33, 1);
echo date('d/m/Y', $res) . "\r\n";
$res = findweekdate2(2009, 63, 1);
echo date('d/m/Y', $res) . "\r\n";
?>
arne_v (17) skrev:
MySQL har f.eks. både en DATETIME type som gemmes som yyyymmdd og hhmmss og en TIMESTAMP type som gemmes som Unix tid.
I de fleste tilfælde er det ligegyldigt om man vælger den ene eller den anden.
Den største forskel er at Unix tid er UTC tid ikke lokal tid.
Den største forskel i værdien isoleret.
Den største forskel generelt er, at TIMESTAMP felter (medmindre man disabler det) automatisk opdaterer til NOW() hver gang rækken opdateres.
Det har en stor praktisk betydning.
windcape (16) skrev:Med typisk ORM kan du jo netop mappe et DATE eller DATETIME field til en specifik type direkte, hvor unixtime er et Integer felt, og derfor kræver ekstra mapping, hvis det givne ORM framework overhovedet tillader det.
UNIXTIME behøver ikke være et INTEGER felt. Det er det f.eks. ikke i MySQL.
Et TIMESTAMP felt i MySQL kræver ikke noget specielt (i NHibernate).
windcape (18) skrev:Jeg vil stadig fraråde det i .NET, da ORM frameworks som Linq2Entities er svære at skrive manuelle mappings til.
Hvis vi nu snakker om INTEGER felt.
LINQ2EF's problem.
I NHibernate laver man bare en ekstra property som konverterer.
windcape (18) skrev:Det er vel også ret meningsløst at gemme som UNIXTIME, når både SQL og alle ORM produkter, baserere sine APIs på at det er DATE/DATETIME.
Det er ret meningsløst at gemme i et INTEGER felt.
TIMESTAMP kan udmærket give mening.
Folk gør ellers stort set aldrig andet.arne_v (76) skrev:Det er ret meningsløst at gemme i et INTEGER felt.
Blev helt overrasket da du nævnte TIMESTAMP som field-type. Havde jeg aldrig hørt om før, og har ikke set et eneste open-source project som benytter MySQL, bruge TIMESTAMP some field-type, de sidste tjah.. 6 år?
Det gør man også i Linq2ef, men hele essensen er jo at du slipper for at arbejde meget med mappings, og ikke skal skrive mange store tunge XML filer, som (n)Hibernate kræver.arne_v (76) skrev:I NHibernate laver man bare en ekstra property som konverterer.
Desuden var fidomuh's argument jo også at unixtime var nemmere at arbejde med fra kode, typisk fordi han ikke gider lære et Date/Time API, som DateTime klassen in PHP5.
windcape (37) skrev:At alle funktionerne der bearbejder datoer der, benytter DATETIME som argument (faktisk en string, for at være præcis), ikke TIMESTAMP.
Nej. De virker både med DATETIME og TIMESTAMP felter.
De virker også med strenge som kan konverteres til DATETIME/TIMESTAMP. Og det bruger de i eksemplerne da det er mest praktisk.
#datetime vs. unixtime
Jeg synes at diskussionen kørte lidt af sporet.
Der er 3 muligheder for data type:
A) En tid type som gemmer de enkelte komponter af tiden. Det bruger MySQL for DATETIME, DATE og TIME. C bruger det for struct tm.
B) En tid type som gemmer antal enheder siden et absolut tidspunkt, Det bruger MySQL for TIMESTAMP. C bruger det for time_t.. NET bruger det for DateTime. Java bruger det for Date.
C) En tal type som gemmer i samme format som B. Det svarer til at gemme Unix tid i et integer felt.
#C er ikke god fordi man ikke kan bruge al den indbyggede support for dato og tidsoperationer.
#A og #B kan begge fint bruges.
#A er nemmest til at pille ymdhms dele ud og til skæve operationer såsom at ligge en måned eller et år til (fordi disse ikke er lige lange).
#B er nemmest til at simple operationer såsom at ligge dage eller timer til (fordi disse er lige lige lange) og til at håndtere tidszoner.
Det er naturligvis muligt at konvertere mellem en tid i form af tidskomponenter og en tid i form af enheder siden et absolut tidspunkt. Men bemærk at en sådan konvertering er kalender specifik.
Ugenumre er et helvede uanset hvad. Og det gør det ikke bedre at MS aldrig har kunnet udregne korrekte ISO 8601 uge numre.
Men fakta er at et MySQL TIMESTAMP og en .NET DateTime gemmer tid i samme form. Der er bare forskelligt basis tidspunkt (1970 og 1) og forskellig enhed (sekunder og 100 nano sekunder).
Der er så to muligheder for at tilgå data.
X) Procedurelt. SQL, C, PHP.
Y) Objekt orienteret. .NET, Java, PHP.
#Y er måske nok en lille smule pænere end #X. Men #X har fungeret fint i 50 år.
Man kan se forskellen i PHP 5.2+:
De fleste vil nok foretrække den sidste variant. Men forskellen er såmænd ikke så stor.
Men bemærk at #X vs #Y er uafhængigt af #A vs #B vs #C.
Jeg synes at diskussionen kørte lidt af sporet.
Der er 3 muligheder for data type:
A) En tid type som gemmer de enkelte komponter af tiden. Det bruger MySQL for DATETIME, DATE og TIME. C bruger det for struct tm.
B) En tid type som gemmer antal enheder siden et absolut tidspunkt, Det bruger MySQL for TIMESTAMP. C bruger det for time_t.. NET bruger det for DateTime. Java bruger det for Date.
C) En tal type som gemmer i samme format som B. Det svarer til at gemme Unix tid i et integer felt.
#C er ikke god fordi man ikke kan bruge al den indbyggede support for dato og tidsoperationer.
#A og #B kan begge fint bruges.
#A er nemmest til at pille ymdhms dele ud og til skæve operationer såsom at ligge en måned eller et år til (fordi disse ikke er lige lange).
#B er nemmest til at simple operationer såsom at ligge dage eller timer til (fordi disse er lige lige lange) og til at håndtere tidszoner.
Det er naturligvis muligt at konvertere mellem en tid i form af tidskomponenter og en tid i form af enheder siden et absolut tidspunkt. Men bemærk at en sådan konvertering er kalender specifik.
Ugenumre er et helvede uanset hvad. Og det gør det ikke bedre at MS aldrig har kunnet udregne korrekte ISO 8601 uge numre.
Men fakta er at et MySQL TIMESTAMP og en .NET DateTime gemmer tid i samme form. Der er bare forskelligt basis tidspunkt (1970 og 1) og forskellig enhed (sekunder og 100 nano sekunder).
Der er så to muligheder for at tilgå data.
X) Procedurelt. SQL, C, PHP.
Y) Objekt orienteret. .NET, Java, PHP.
#Y er måske nok en lille smule pænere end #X. Men #X har fungeret fint i 50 år.
Man kan se forskellen i PHP 5.2+:
<?php
date_default_timezone_set('Europe/Copenhagen');
// PP style
$dt = date_create();
date_isodate_set($dt, 2009, 33, 1);
echo date_format($dt, 'd/m/Y') . "\r\n";
// OOP style
$dt = new DateTime();
$dt->setISODate(2009, 33, 1);
echo $dt->format('d/m/Y') . "\r\n";
?>
De fleste vil nok foretrække den sidste variant. Men forskellen er såmænd ikke så stor.
Men bemærk at #X vs #Y er uafhængigt af #A vs #B vs #C.
windcape (78) skrev:Det gør man også i Linq2ef, men hele essensen er jo at du slipper for at arbejde meget med mappings, og ikke skal skrive mange store tunge XML filer, som (n)Hibernate kræver.
Mappings bliver ikke større fordi man bruger en ekstra property i sin klasse.
LINQ2EF har vist iøvrigt betydeligt større XML filer end NHibernate.
Forskellen er bare t MS leverer tools til at generere de XML filer med. Det gør NHibernate ikke. Men der findes 3. parts produkter som kan generere mappings for NHibernate.
Og så lige en stribe korrektioner.
date("w",ts) giver day in week - det er date("W",ts) som giver week in year.
Det kan du nu sagtens is_int, is_double etc. afslører det.
I mangel af en egnet decimal type i PHP, så bør penge opbevares som heltals ører.
DBA er en job titel ikke en uddannelse.
Der er så mange fejl i den linie, at det er svært at gætte på hvad det skulle være.
Måske:
$ts = strtotime('+1 day', $ts);
Og den er også invalid PHP syntax.
fidomuh (30) skrev:Som en ret daarlig loesning kunne du jo finde foerste dag i foerste uge, regne +33 uger og saa tjekke om date("w",[timestamp]) giver dig 33 :)
fidomuh (60) skrev:Med unixtime skriver jeg date("w",[time]).
date("w",ts) giver day in week - det er date("W",ts) som giver week in year.
fidomuh (49) skrev:Det er PHP, saa jeg kan ikke fortaelle dig om det er en INT eller en Float
Det kan du nu sagtens is_int, is_double etc. afslører det.
I mangel af en egnet decimal type i PHP, så bør penge opbevares som heltals ører.
fidomuh (49) skrev:( Et stykke papir er ikke ensbetydende med at man ved hvad man snakker om )
DBA er en job titel ikke en uddannelse.
fidomuh (64) skrev:Men eh:
time = time(++1d);
Der er så mange fejl i den linie, at det er svært at gætte på hvad det skulle være.
Måske:
$ts = strtotime('+1 day', $ts);
fidomuh (64) skrev:men jeg har nu altid brugt samme funktionsframework ( min egen samling ) som godtager fx myTime(+1d).
Og den er også invalid PHP syntax.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund