[DBase/Mysql/PHP] Datetime convert/weergeven

[vakantieman]

Ik heb sinds enkele dagen een weerstation, deze heeft een applicatie waarmee ik via USB data kan uitlezen, deze slaat de data op in een DBase database. Nu heb ik deze data ingelezen in MySQL. Alleen de DATE_TIME waardes uit die DBase database zien er als volgt uit: 40057,8375.

Nu wil ik deze op mijn website doormiddel van php omzetten naar een gewone datum en tijd notatie. Hier gaat het mis omdat PHP; ik krijg namelijk de volgende datum terug: 01-01-1970 12:07, dit is bij alle datums. Dus PHP kan duidelijk niet met deze DATETIME overweg?

Ik ben even op onderzoek uit gegaan, ik heb niets op google kunnen vinden wat mij enigsinds op de goede weg zou kunnen brengen, het veld in de database heeft op dit moment als type VARCHAR, ik heb dit geprobeerd om te zetten naar DATETIME van MySQL, maar dit maakt het veld leeg.

Mijn vraag is, is er een manier om deze DATE_TIME weer te geven doormiddel van PHP?

[cariolive23]

Alleen de DATE_TIME waardes uit die DBase database zien er als volgt uit: 40057,8375.

En welke datums met tijden zouden dit dan volgens jou moeten zijn? Jouw PHP behandelt deze getallen als unix timestamps en deze beginnen te tellen vanaf 1-1-1970. Zorg er voor dat je échte datums doorgeeft, in het formaat yyyy-mm-dd met evt. de tijd in het formaat hh:mm:ss

[Woy]

cariolive23 schreef op maandag 07 september 2009 @ 09:17:
[...]
Zorg er voor dat je échte datums doorgeeft, in het formaat yyyy-mm-dd met evt. de tijd in het formaat hh:mm:ss

Aangezien je het al over een formaat hebt, zijn het net zo goed "echte datums". Het is gewoon belangrijk dat je weet wat je data inhoud. Op zich hoeft een bepaalde formatering geen probleem te zijn, je moet alleen aan beide kanten weten hoe die is. De "yyyy-mm-dd" notatie is inderdaad wel redelijk geaccepteerd als norm voor locale onafhankelijk formaat.

[cariolive23]

ISO is inderdaad wel redelijk geaccepteerd als een organisatie om standaarden te beheren...

http://www.iso.org/iso/catalogue_detail.htm?csnumber=26780

[Woy]

cariolive23 schreef op maandag 07 september 2009 @ 09:54:
ISO is inderdaad wel redelijk geaccepteerd als een organisatie om standaarden te beheren...

http://www.iso.org/iso/catalogue_detail.htm?csnumber=26780

Maar ook met een ISO standaard moet je wel aan beide kanten weten dat je die hanteert , Unix Timestamps zijn ook redelijk geaccepteerd als date-time formaat, maar als je niet weet wat je data precies betekent dan ben je nergens.

[Kalentum]

vakantieman schreef op maandag 07 september 2009 @ 08:56:
Ik heb sinds enkele dagen een weerstation, deze heeft een applicatie waarmee ik via USB data kan uitlezen, deze slaat de data op in een DBase database. Nu heb ik deze data ingelezen in MySQL. Alleen de DATE_TIME waardes uit die DBase database zien er als volgt uit: 40057,8375.

Nu wil ik deze op mijn website doormiddel van php omzetten naar een gewone datum en tijd notatie. Hier gaat het mis omdat PHP; ik krijg namelijk de volgende datum terug: 01-01-1970 12:07, dit is bij alle datums. Dus PHP kan duidelijk niet met deze DATETIME overweg?

Ik ben even op onderzoek uit gegaan, ik heb niets op google kunnen vinden wat mij enigsinds op de goede weg zou kunnen brengen, het veld in de database heeft op dit moment als type VARCHAR, ik heb dit geprobeerd om te zetten naar DATETIME van MySQL, maar dit maakt het veld leeg.

Mijn vraag is, is er een manier om deze DATE_TIME weer te geven doormiddel van PHP?

Type VARCHAR? Ik ben bang dat de fabrikant van dat weerstation dan zelf een formaatje heeft bedacht. Is er geen documentatie bijgeleverd of te vinden op de site van de fabrikant?

[vakantieman]

rutgerw schreef op maandag 07 september 2009 @ 10:15:
[...]


Type VARCHAR? Ik ben bang dat de fabrikant van dat weerstation dan zelf een formaatje heeft bedacht. Is er geen documentatie bijgeleverd of te vinden op de site van de fabrikant?

Ik dacht eerst ook dat het een zelf bedacht formaatje is, maar toen ik de DBase database opende in Excel kon ik wel het genoemde veld als Datum aanwijzen, en excel kon het formaat dus aan. Dus het geaccepteerd formaat zijn.

[ValHallASW]

vakantieman schreef op maandag 07 september 2009 @ 11:21:
Ik dacht eerst ook dat het een zelf bedacht formaatje is, maar toen ik de DBase database opende in Excel kon ik wel het genoemde veld als Datum aanwijzen, en excel kon het formaat dus aan. Dus het geaccepteerd formaat zijn.

Excel gebruikt dagen sinds 1 januari 1900. Of sinds 1 januari 1904, als je een mac-versie gebruikt. Even checken wat het goede formaat is dus

Overigens: waarmee heb je je data geconverteerd? DBase gebruikt dit formaat namelijk helemaal niet:

quote: http://www.dbase.com/knowledgebase/int/db7_file_fmt.htm

@ Timestamp 8 bytes - two longs, first for date, second for time. The date is the number of days since 01/01/4713 BC. Time is hours * 3600000L + minutes * 60000L + Seconds * 1000L

[ Voor 27% gewijzigd door ValHallASW op 07-09-2009 11:32 ]

[Kalentum]

ValHallASW schreef op maandag 07 september 2009 @ 11:26:
[...]

Excel gebruikt dagen sinds 1 januari 1900. Of sinds 1 januari 1904, als je een mac-versie gebruikt. Even checken wat het goede formaat is dus
[...]

Dan is dat het. 1 jan 1900 + 40057 dagen = 3 september 2009

[jbdeiman]

@vakantieman

Kan je eens een datum (in gewone notatie) en een datum zoals die wordt gegeven naast elkaar zetten? Dan kunnen we misschien wat makkelijker bepalen hoe het zit. Tot nu toe heb ik alleen dit gevonden, maar als ik naar jou datum kijk zoals die wordt gemaakt voldoet die aan geen enkele standaard.

http://www.cl.cam.ac.uk/~mgk25/iso-time.html


Overigens kan je met DBASE niet een query maken die de datum wel goed weergeeft en deze dan gebruiken?

[vakantieman]

ValHallASW schreef op maandag 07 september 2009 @ 11:26:
[...]

Excel gebruikt dagen sinds 1 januari 1900. Of sinds 1 januari 1904, als je een mac-versie gebruikt. Even checken wat het goede formaat is dus

Overigens: waarmee heb je je data geconverteerd? DBase gebruikt dit formaat namelijk helemaal niet:
[...]

Dat zal waarschijnlijk het programma van het weerstation voor me doen. Is er een functie binnen PHP die dit makkelijk kan converteren want deze meeste functies werken met een UNIX Timestamp?

jbdeiman schreef op maandag 07 september 2009 @ 11:48:
@vakantieman

Kan je eens een datum (in gewone notatie) en een datum zoals die wordt gegeven naast elkaar zetten? Dan kunnen we misschien wat makkelijker bepalen hoe het zit. Tot nu toe heb ik alleen dit gevonden, maar als ik naar jou datum kijk zoals die wordt gemaakt voldoet die aan geen enkele standaard.

http://www.cl.cam.ac.uk/~mgk25/iso-time.html


Overigens kan je met DBASE niet een query maken die de datum wel goed weergeeft en deze dan gebruiken?

Hier een datum voorbeeld:

6 september 2009 18:11 --> 40062,757639

[ Voor 36% gewijzigd door vakantieman op 07-09-2009 12:58 ]

[ValHallASW]

Ik ken 'm niet, maar hij is zo simpel dat je 'm zelf wel kunt schrijven. UNIX epoch is 1 jan 1970. Dat zijn 365.25*70=25567,5 dagen (bedenk zelf maar hoe het met schrikkeljaren zit ). Dan heb je het aantal dagen sinds de unix epoch; vermenigvuldig met het aantal secondes in een dag (86400) en je hebt een unix timestamp. Ow, wel nog even uitkijken met tijdzones enzo.

[Creepy]

O.a. Delphi 7 en kleiner (van 8 en hoger weet ik niet het zeker i.v.m. .NET e.d.) slaan een DateTime type op precies dezelfde manier op

[jan-marten]

Hoi Vakantieman.
Heb je toevallig een TFA-Nexus weerstation gekocht?
Zo ja, dan ben ik ook wel benieuwd naar wat jij aan het fabriceren bent. Ik heb hem zelf ook en heb een tijdje geleden ook iets geschreven (DBase -> MySQL conversie).

De datum/tijd notatie is trouwens een ouderwetse OLE Automation date.
Volgens MSDN:

An OLE Automation date is implemented as a floating-point number whose value is the number of days from midnight, 30 December 1899. For example, midnight, 31 December 1899 is represented by 1.0; 6 A.M., 1 January 1900 is represented by 2.25; midnight, 29 December 1899 is represented by -1.0; and 6 A.M., 29 December 1899 is represented by -1.25.

The base OLE Automation Date is midnight, 30 December 1899. The maximum OLE Automation Date is the same as MaxValue, the last moment of 31 December 9999.

Het getal voor de komma is het aantal dagen na 31 dec 1899. Het getal na de komma is het dagdeel (0,5 is bijvoorbeeld 12 uur 's middags, 0,75 is 6 uur 's avonds).

Hoop dat je hier wat mee kunt.

[vakantieman]

Ik heb inderdaad de TFA_Nexus gekocht, ik heb op dit moment het volgende in mijn hoofd:

- Commandline script die Dbase file exporteert naar csv en via ftp upload naar server
- PHP script maken die csv file inleest in mysql database
- Doormiddel van XML/SWF charts de data in grafieken weergeven.

Ik ben niet zo'n guru dat ik zelf even een conversie scriptje schrijf, maar via google heb ik wel een conversie script gevonden die zoals ik het nu kan zie goed werkt. Ik weet niet of het toegestaan is om hierna te linken of dit hier te plaatsen.

Maar in ieder geval iedereen bedankt voor de hulp en reacties!!

[Duroth]

* Duroth denkt wellicht wel veel te simpel...

php: function.mktime?

[Verwijderd]

Creepy schreef op maandag 07 september 2009 @ 13:19:
O.a. Delphi 7 en kleiner (van 8 en hoger weet ik niet het zeker i.v.m. .NET e.d.) slaan een DateTime type op precies dezelfde manier op

Delphi 2009 for Win32 gebruikt ook nog steeds de OLE Automation date, een double dus met 1899-12-30 00:00.000 als nul-datum. Delphi PRISM gebruikt de DateTime structure van 't .NET framework.

[T-MOB]

Duroth schreef op maandag 07 september 2009 @ 17:07:
* Duroth denkt wellicht wel veel te simpel...

php: function.mktime?

Ja je denkt een beetje te simpel. Het eerste probleem is dat PHP's interne timestamps niet op elk systeem teruggaan tot de basisdatum:

On systems where time_t is a 32bit signed integer, as most common today, the valid range for year is somewhere between 1901 and 2038

mktime(0,0,0,1,1,1900) geeft je op een 32 bit-systeem geen output. Daarmee is de beste_TM manier om het probleem verder mee te tackelen (strtotime()) onbruikbaar.

Het tweede probleem zit hem in het bepalen van de tijd. Ik ben erg benieuwd wat de Ole automation date doet met daylight saving time. Dagen hebben helemaal geen constante lengte. Op de dag dat zomertijd ingaat duurt de dag maar 23 uur en hoe laat is {dag},25 dan?

[ValHallASW]

T-MOB schreef op dinsdag 08 september 2009 @ 11:17:
Dagen hebben helemaal geen constante lengte. Op de dag dat zomertijd ingaat duurt de dag maar 23 uur en hoe laat is {dag},25 dan?

Een dag duurt nog steeds (bij benadering) 24 uur hoor. Als je zomertijd verwerkt in je datamodel dan ben je iets grondig fout aan het doen. Gewoon GMT opslaan, het omrekenen naar de lokale tijd doe je later maar.

[jan-marten]

vakantieman schreef op maandag 07 september 2009 @ 17:00:
Ik heb inderdaad de TFA_Nexus gekocht, ik heb op dit moment het volgende in mijn hoofd:

- Commandline script die Dbase file exporteert naar csv en via ftp upload naar server
- PHP script maken die csv file inleest in mysql database
- Doormiddel van XML/SWF charts de data in grafieken weergeven.

Ik ben niet zo'n guru dat ik zelf even een conversie scriptje schrijf, maar via google heb ik wel een conversie script gevonden die zoals ik het nu kan zie goed werkt. Ik weet niet of het toegestaan is om hierna te linken of dit hier te plaatsen.

Maar in ieder geval iedereen bedankt voor de hulp en reacties!!

Als je interesse hebt wil ik mijn programma wel met jouw delen. Ik heb het momenteel wel in VB.NET geschreven maar dat is gemakkelijk te vertalen naar C#.NET oid.

De display kant in PHP had ik willen doen met oa ajax dingetjes en grafieken met jpGraph. Hier ben ik helaas niet meer aan toe gekomen.

[jbdeiman]

Oplossing:

PHP:

<?php
//Datum invoer
$testdate = 40062.757639;
//Knip datum op in aantal hele dagen en deel van dag
list($days,$daypart) = explode('.',$testdate);
//bereken het aantal seconden per dag
$seconds_day = 60*60*24;
//bereken het aantal seconden dat erbij moet worden opgeteld
$seconds_plus = floatval('0.'.$daypart) * $seconds_day;
//Bepaal de nieuwe datum
$new_date = date('Y-m-d H:i:s',mktime(0,0,0+$seconds_plus,12,30+$days,1899));

echo $basic_date.' '.$new_date;
?>

Werkt prima, heb het getest met de waarde die je zelf als voorbeeld had gegeven en krijg keurig de juiste datum terug.

[ Voor 4% gewijzigd door jbdeiman op 08-09-2009 12:14 ]