[JAVA/DB] INSERT Query komt niet door

[Teeno]

Beste mensen, ik kan hier kort of lang over lullen, maar ik zal hieronder in het kort het een en ander uitleggen. Als database heb ik zowel MS Access als SQLite (tip uit #devschuur) gebruikt, met beide hetzelfde resultaat.

Geconstateerd:

• Vanuit de applicatie een INSERT query uitvoeren levert geen record op in de database
• De query wordt geprint in de console. Bij een c/p in MS Access / SQLite wordt de record wel toegevoegd
• De rest van de applicatie (welke vooralsnog uit SELECT queries bestaat) werkt perfect

Concrete vraag
Op welke manier is te achterhalen waar de fout zit, waarbij ik vooral benieuwd ben of het in de applicatie, of in de database zit. Dat laatste lijkt me onwaarschijnlijk gezien het feit dat met twee verschillende databases hetzelfde resultaat terugkeert.

[Daspeed]

Misschien zou je kunnen beginnen met posten van een stukje relevante code

[Teeno]

DrClearbottom schreef op maandag 05 november 2007 @ 10:08:
Misschien zou je kunnen beginnen met posten van een stukje relevante code

Ik wist dat die vraag zou komen.

Waar zit je aan te denken? De query is goed, de connectie is goed (die wordt met alle queries hetzelfde opgebouwd)

[ Voor 30% gewijzigd door Teeno op 05-11-2007 10:22 ]

[TeeDee]

Laat maar gewoon de relevante code zien waarmee je een insert tracht te maken.

[Daspeed]

idd, opbouwen connectie + code om insert-query uit te voeren

[Teeno]

Ik heb een lead binnen de DB klasse gevonden, zal deze even op de Grissom-manier uitzoeken... Ik hou jullie op de hoogte

[whoami]

Als je geen code wil posten, dan kunnen we je ook niet verder helpen, en dan zie ik ook geen nut meer in dit topic ....

Zowiezo, een SELECT query zal je hoogstwaarschijnlijk op een andere manier moeten aanroepen in Java, dan een INSERT query. De ene query returned nl. een result-set, en de andere niet ...

[Teeno]

whoami schreef op maandag 05 november 2007 @ 10:27:
Zowiezo, een SELECT query zal je hoogstwaarschijnlijk op een andere manier moeten aanroepen in Java, dan een INSERT query. De ene query returned nl. een result-set, en de andere niet ...

Daar ben ik inderdaad achter, ik vind het wel vreemd omdat dezelfde database klasse wel in vorige projecten heeft gewerkt... Zoals ik in mijn vorige post vermeldde ga ik even goed bekijken waar het precies misgaat. mocht ik er niet uitkomen zal ik wat code posten.

[Confusion]

Je zit in een transactie en voert geen commit uit? Verschil met vroeger: 'autocommit' staat nu standaard uit?

[ Voor 36% gewijzigd door Confusion op 05-11-2007 10:34 ]

[Pete]

Teeno schreef op maandag 05 november 2007 @ 10:29:
[...]

Daar ben ik inderdaad achter, ik vind het wel vreemd omdat dezelfde database klasse wel in vorige projecten heeft gewerkt... Zoals ik in mijn vorige post vermeldde ga ik even goed bekijken waar het precies misgaat. mocht ik er niet uitkomen zal ik wat code posten.

Een ander gooi dan. Heeft de SQL-user wel insert rechten? (En wat voor debugging heb je al in je code gedaan? Krijg je geen foutmeldingen terug van je statement?)

[ Voor 10% gewijzigd door Pete op 05-11-2007 10:36 ]

[whoami]

Teeno schreef op maandag 05 november 2007 @ 10:29:
[...]

Daar ben ik inderdaad achter, ik vind het wel vreemd omdat dezelfde database klasse wel in vorige projecten heeft gewerkt... Zoals ik in mijn vorige post vermeldde ga ik even goed bekijken waar het precies misgaat. mocht ik er niet uitkomen zal ik wat code posten.

whoami schreef op maandag 05 november 2007 @ 10:27:
Als je geen code wil posten, dan kunnen we je ook niet verder helpen, en dan zie ik ook geen nut meer in dit topic ....

Als we alleen maar kunnen gissen, omdat jij jouw geheime code niet wilt posten, dan komen we nergens.

[whoami]

whoami in "Feedback op moderatie binnen de Devschuu..."

[Teeno]

Bij deze;

Ik zal even laten zien waar hij uiteindelijk op uit komt

Java:

    public void executeQuery() {
        try {
            // voer de query uit
            resultSet = statement.executeQuery(queryString);

            // toon een bericht als dat gewenst is
            showMessage(QUERY_EXECUTED_MESSAGE[this.getLanguage()] +
                        ON_DATABASE_MESSAGE[this.getLanguage()] +
                        dataBaseName);

        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }

Wat echter raar is, is dat dezelfde methode in een ander project wel werkt... hij voert dus geen harde insert uit maar creëert een resultset... daarom werken de select queries wel.

de printStackTrace stond er nog niet in, nu krijg ik dus wat rode text;

code:

Huidige query: INSERT INTO Orders(Ship_OrderID, ShipID, Date1, Date2, Period, Description, Officer, Master) Values("1337", "4", "November 3, 2007", "3-11-2007", "URGENT", "Paint", "testing", "also testing");

    at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
    at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
    at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
    at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
    at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
    at java.awt.Component.processMouseEvent(Unknown Source)
    at javax.swing.JComponent.processMouseEvent(Unknown Source)
    at java.awt.Component.processEvent(Unknown Source)
    at java.awt.Container.processEvent(Unknown Source)
    at java.awt.Component.dispatchEventImpl(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
    at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
    at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Window.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)
Database is gesloten: TSS-Database

[ Voor 3% gewijzigd door Teeno op 05-11-2007 11:04 ]

[Daspeed]

is je databaseconnectie wel open dan?

[TeeDee]

Ik zie nergens dat je je connection opent.

[Teeno]

Vanuit de console

code:

java.sql.SQLException: [Microsoft][ODBC Microsoft Access-stuurprogramma] De haakjes rond de naam [M. de Jong] zijn niet geldig.
    at sun.jdbc.odbc.JdbcOdbc.createSQLException(Unknown Source)
    at sun.jdbc.odbc.JdbcOdbc.standardError(Unknown Source)
    at sun.jdbc.odbc.JdbcOdbc.SQLExecDirect(Unknown Source)
    at sun.jdbc.odbc.JdbcOdbcStatement.execute(Unknown Source)
    at sun.jdbc.odbc.JdbcOdbcStatement.executeQuery(Unknown Source)
    at DB.executeQuery(DB.java:303)
    at DB.Database_Aanroep(DB.java:490)
    at NewOrder$3.actionPerformed(NewOrder.java:144)Database stuurprogramma is geladen
Database verbinding is tot stand gebracht: TSS-Database
Metadata is opgehaald: TSS-Database

Metadata: 

admin
ACCESS
04.00.0000
JDBC-ODBC Bridge (odbcjt32.dll)

Hierna begint ie met het printen van de query

Wat betreft de ongeldige haakjes, kan dit te maken hebben met de quotjes om de values? Als ik een naam opgeef die geen punt (.) bevat geeft hij de volgende melding

code:

java.sql.SQLException: [Microsoft][ODBC Microsoft Access-stuurprogramma] Er zijn te weinig parameters. Het verwachte aantal is: 8.

[whoami]

Waarom zet je (dubbele) quotes rond al je waardes in je query ? Op die manier worden numerieke gegevens en datums als strings behandeld.
Waarom gebruik je geen geparametrizeerde queries ?

[Daspeed]

die query gaat wel goed als je hem in access/sqlite uitvoert?

[sjongenelen]

een insert is toch geen query? ik ben geen expert maar ik heb ooit wel eens de fout gemaakt een UPDATE commando te geven met executeQuery, wat Updatequery executeUpdate bleek te moeten zijn..

[ Voor 5% gewijzigd door sjongenelen op 05-11-2007 11:26 ]

[Teeno]

whoami schreef op maandag 05 november 2007 @ 11:26:
Waarom zet je (dubbele) quotes rond al je waardes in je query ? Op die manier worden numerieke gegevens en datums als strings behandeld.
Waarom gebruik je geen geparametrizeerde queries ?

Er zijn geen vaste numerieke gegevens. ID's kunnen ook tekst bevatten en datums kunnen worden ingevoerd als November 5, 2007 bijvoorbeeld. Alleen het ShipID is numeriek.. maar die quotes zal ik er nu even uithalen.

DrClearbottom schreef op maandag 05 november 2007 @ 11:26:
die query gaat wel goed als je hem in access/sqlite uitvoert?

Dat klopt

TheNymf schreef op maandag 05 november 2007 @ 11:26:
een insert is toch geen query? ik ben geen expert maar ik heb ooit wel eens de fout gemaakt een UPDATE commando te geven met executeQuery, wat Updatequery executeUpdate bleek te moeten zijn..

Ik heb dat nu dmv een parameter (type = 0 of 1) afgehandeld, helaas geen resultaat

Java:

        // voer een query uit
        if (type == 0) {
            executeQuery();
        }
        // voer een update uit
        else if (type == 1) {
            executeUpdate();
        }

executeUpdate doet nu dit

Java:

    public void executeUpdate() {
        try {
            statement.executeUpdate(queryString);
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

[Confusion]

Teeno schreef op maandag 05 november 2007 @ 11:41:
ID's kunnen ook tekst bevatten en datums kunnen worden ingevoerd als November 5, 2007 bijvoorbeeld.

Hoe een datum kan worden ingevoerd heeft natuurlijk niets te maken met hoe je een datum in een database opslaat. Datums sla je op in het datumformaat. Met elke andere manier snij je jezelf hopeloos in de vingers.

Daarnaast heeft TheNymf sowieso gelijk: executeQuery werkt niet met queries die geen resultset opleveren. Daar zijn andere methoden, zoals executeUpdate voor. Maar als je executeQuery gebruikt, dan krijg je een mooie exceptie terug, die je precies hetzelfde verteld. Heb je zelf al enige poging tot debugging gedaan?

[ Voor 27% gewijzigd door Confusion op 05-11-2007 11:52 ]

[whoami]

Teeno schreef op maandag 05 november 2007 @ 11:41:
[...]

datums kunnen worden ingevoerd als November 5, 2007 bijvoorbeeld.

En dan ? Die datum kan perfect omgezet worden naar een datetime, en zo opgeslagen worden.
Als jij datums gaat opslaan als 'November 5, 2007' en '5/11/2007' en deze dus zo als string opslaat, hoe ga jij dan alle records kunnen terugvinden die als datum 5 november 2007 hebben ?

[Janoz]

Goed, dat ID's ook tekstueel kunnen zijn kan ik inkomen, maar dat de invoer van een datum het veldtype definieert vind ik behoorlijke prutserij.

hmmm spuit 231732891

[ Voor 7% gewijzigd door Janoz op 05-11-2007 11:52 ]

[Teeno]

whoami schreef op maandag 05 november 2007 @ 11:50:
[...]

En dan ? Die datum kan perfect omgezet worden naar een datetime, en zo opgeslagen worden.
Als jij datums gaat opslaan als 'November 5, 2007' en '5/11/2007' en deze dus zo als string opslaat, hoe ga jij dan alle records kunnen terugvinden die als datum 5 november 2007 hebben ?

Excuses, wat ik dus bedoelde is dat de datums wel vast worden ingevoerd.. maar dus éénmalig als November 5, 2007, en één als 5-11-2007 (date1 en date2 in de tabel). Ik heb altijd al moeite gehad met het converseren van data.

Als we deze datumdiscussie voort willen zetten kunnen we dat beter in een ander topic doen? Anders zien we zo door de bomen het bos niet meer

[sjongenelen]

ik sla alle datum als long op ( in textfield)

stukje code opgedoekt:

Java:

** --------------------------------------------------------------------------------
     * 2.0. getNow
     * 
     * De methode getNow geeft de huidige tijd terug als long
     * ------------------------------------------------------------------------------- */     
        public long getNow()
        {
            java.util.Date date = new java.util.Date();
            long antwoord = date.getTime();
            
            return antwoord;
        }

oftewel java.util.date lib

[ Voor 3% gewijzigd door sjongenelen op 05-11-2007 12:05 ]

[Confusion]

Teeno schreef op maandag 05 november 2007 @ 11:56:
Als we deze datumdiscussie voort willen zetten kunnen we dat beter in een ander topic doen?

Het is geen discussie: het zijn drie mensen die je vertellen dat je het beter anders kunt doen. En wat betreft datumconversies: java.util.SimpleDateFormatter. De documentatie is glashelder. Read it, use it.

Heb je al een keer een connection.commit() na je executeUpdate gedaan?

[ Voor 8% gewijzigd door Confusion op 05-11-2007 12:03 ]

[whoami]

Jij je zin, maar zoals Confusion zegt: het is geen discussie. Het is een raad.

Wat is 'M. De Jong' in je eerste foutmelding (een waarde die je wilt inserten?), en waarom plaats je die tussen block-quotes (die een speciale betekenis hebben in Access & SQL Server).

[ Voor 14% gewijzigd door whoami op 05-11-2007 12:03 ]

[bvp]

Ik heb dat nu dmv een parameter (type = 0 of 1) afgehandeld, helaas geen resultaat

Java:

        // voer een query uit
        if (type == 0) {
            executeQuery();
        }
        // voer een update uit
        else if (type == 1) {
            executeUpdate();
        }

executeUpdate doet nu dit

Java:

    public void executeUpdate() {
        try {
            statement.executeUpdate(queryString);
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

En weet je ook zeker dat ie bij de methode executeUpdate() uitkomt nu dan? M.a.w. is type ook echt 1 > checken met debug / print out voor de statement.execute....

En idd een commit gedaan na de query ?

[Creepy]

TheNymf schreef op maandag 05 november 2007 @ 12:00:
ik sla alle datum als long op ( in textfield)

offtopic:
Waarom niet als long in een long opslaan? Dan kan je in elk geval vanuit je query 1 op 1 datums vergelijken. Dit nog even naast het feit dat een DB ook types heeft voor een datum (Date, DateTime, Timestamp etc.).

[Teeno]

Bij deze even een status rapport;

Om wat makkelijker te debuggen heb ik in de main een eenvoudige INSERT query geplaatst.

Java:

db.Database_Aanroep("INSERT INTO Ships (ShipName, Actief) values ('GROTEBOOT', true)", 1);

de 1 houdt in dat het hier om een Update gaat. En geloof het of niet, na wat spelen met de quotes, haakjes weg of niet werkt ie nu. Ik ga nu proberen de goede querie aan de praat te krijgen.

Tijd om een stukje documentatie te schrijven over het gebruik van quotes en dergelijke, want dat zat er duidelijk nog niet goed in.

[Verwijderd]

Teeno schreef op maandag 05 november 2007 @ 12:37:
Bij deze even een status rapport;

Om wat makkelijker te debuggen heb ik in de main een eenvoudige INSERT query geplaatst.

Java:

db.Database_Aanroep("INSERT INTO Ships (ShipName, Actief) values ('GROTEBOOT', true)", 1);

de 1 houdt in dat het hier om een Update gaat. En geloof het of niet, na wat spelen met de quotes, haakjes weg of niet werkt ie nu. Ik ga nu proberen de goede querie aan de praat te krijgen.

Tijd om een stukje documentatie te schrijven over het gebruik van quotes en dergelijke, want dat zat er duidelijk nog niet goed in.

Je wilt zeggen dat je in de documentatie moet schrijven dat de klasse fatsoenlijk gevormde queries verwacht?

Schande dat dat er niet in staat inderdaad

offtopic:
Ik ben ook fan van het opslaan van datum gegevens in long formaat, maar dan wel gewoon ook als long in de DB

[ Voor 6% gewijzigd door Verwijderd op 05-11-2007 12:41 ]

[Teeno]

whoami schreef op maandag 05 november 2007 @ 12:02:
Jij je zin, maar zoals Confusion zegt: het is geen discussie. Het is een raad.

Wat is 'M. De Jong' in je eerste foutmelding (een waarde die je wilt inserten?), en waarom plaats je die tussen block-quotes (die een speciale betekenis hebben in Access & SQL Server).

Ik heb nergens block-quotes meegegeven, de reden dat die daar dus wel staan was mij compleet onduidelijk

[Teeno]

Verwijderd schreef op maandag 05 november 2007 @ 12:41:
[...]

Je wilt zeggen dat je in de documentatie moet schrijven dat de klasse fatsoenlijk gevormde queries verwacht?

Schande dat dat er niet in staat inderdaad

Wat is dit nu weer voor een opmerking, ik bedoelde een stukje voor mezelf, buiten de documentatie om... Maargoed.. iedereen is hier als expert geboren neem ik maar aan dan

[Verwijderd]

Je hoeft niet als expert te zijn geboren, maar je kunt wel gewoon lezen toch?

whoami schreef op maandag 05 november 2007 @ 11:26:
Waarom zet je (dubbele) quotes rond al je waardes in je query ? Op die manier worden numerieke gegevens en datums als strings behandeld.
Waarom gebruik je geen geparametrizeerde queries ?

[voodooless]

TheNymf schreef op maandag 05 november 2007 @ 12:00:

Java:

** --------------------------------------------------------------------------------
     * 2.0. getNow
     * 
     * De methode getNow geeft de huidige tijd terug als long
     * ------------------------------------------------------------------------------- */     
        public long getNow()
        {
            java.util.Date date = new java.util.Date();
            long antwoord = date.getTime();
            
            return antwoord;
        }

Wat is er mis met System.currentTimeMillis()

[RobIII]

Verwijderd schreef op maandag 05 november 2007 @ 12:41:

offtopic:
Ik ben ook fan van het opslaan van datum gegevens in long formaat, maar dan wel gewoon ook als long in de DB

Dat snap ik dan weer nooit; hoe doe jij dan een "select * from sometable where month(somefield) = 3" ? Of hoe haal jij alle gegevens per kwartaal/weeknummer op? Of...? Jezelf eerst scheel rekenen om die data allemaal om te rekenen naar long voordat je ze in de query gooit?
Waarom zou je datum opslaan als een long als er een date/datetime/time type is?

[ Voor 16% gewijzigd door RobIII op 05-11-2007 13:04 ]

[BalusC]

Summarizerend:

1) Gebruik in DB het juiste veldtype voor de waarde. Gebruik DATETIME / TIMESTAMP voor datums.
2) Gebruik PreparedStatement om queries met variabelen te voorbereiden. Het biedt methoden om datums te zetten.
3) Gebruik de juiste methode om de query te uitvoeren. Voor INSERT is deze executeUpdate().
4) Controleer autoCommit en zet deze evt naar true of gebruik Connection#commit().
5) Leer de API documentatie te begrijpen.

[ Voor 9% gewijzigd door BalusC op 05-11-2007 13:18 ]

[voodooless]

RobIII schreef op maandag 05 november 2007 @ 13:03:
Dat snap ik dan weer nooit; hoe doe jij dan een "select * from sometable where month(somefield) = 3" ? Of hoe haal jij alle gegevens per kwartaal/weeknummer op? Of...? Jezelf eerst scheel rekenen om die data allemaal om te rekenen naar long voordat je ze in de query gooit?
Waarom zou je datum opslaan als een long als er een date/datetime/time type is?

De meeste DB's kunnen hier prima mee overweg, ook als je gewoon UTC longs gebruikt.

[Verwijderd]

RobIII schreef op maandag 05 november 2007 @ 13:03:
[...]

Dat snap ik dan weer nooit; hoe doe jij dan een "select * from sometable where month(somefield) = 3" ? Of hoe haal jij alle gegevens per kwartaal/weeknummer op? Of...? Jezelf eerst scheel rekenen om die data allemaal om te rekenen naar long voordat je ze in de query gooit?
Waarom zou je datum opslaan als een long als er een date/datetime/time type is?

Die discussies hebben we al eens uitgebreid gehad en lijkt me hier niet handig, dat kan beter in een apart topic.

Laten we het erop houden dat ik de UNIX timestamp manier om tijd weer te geven een fundamenteel betere manier vind dan iedere andere vorm. Zeker in de westerse wereld waar de meeste tijdformaten gebaseerd zijn op de Gregoriaanse kalender, een kalender die zelf al een stapel bugs had waar je U tegen zegt. De UNIX timestamp is een hele absolute manier om tijd weer te geven, dat vind ik er prettig en goed aan.

Daarnaast werken alle systemen die ik gebruik ermee (waaronder de database zoals voodooless al zegt), maar heeft de database ook nog eens z'n eigen timestamp formaat (waar in het verleden en ook nu een hoop problemen mee zijn geweest). Door gebruik te maken van de UNIX timestamp kan ik gebruik maken van bibliotheken die al zo oud zijn als de kont van Sinterklaas en dus de test of time hebben doorstaan.

Ik schrijf graag een query iets ingewikkelder mits dat geen performance issues geeft (wat het in mijn nederige ervaring nog nooit heeft gedaan) als ik dan al die ellende van een eigen slecht opgezet timestamp formaat niet op m'n kop haal.

Het is dus niet alleen gebaseerd op praktische redenen, maar ook theoretische redenen.

Maar to each his own, ik ben nog nooit tegen problemen aangelopen door UNIX timestamp te gebruiken, als jij nog nooit tegen problemen aan bent gelopen door het eigen timestamp formaat te gebruiken dan zijn ze allebei prima toch?

[RobIII]

voodooless schreef op maandag 05 november 2007 @ 13:45:
[...]
De meeste DB's kunnen hier prima mee overweg, ook als je gewoon UTC longs gebruikt.

I know Het ging me meer om het principe. De discussie is, zoals TRRoads al aangeeft, inderdaad al vaker gevoerd. En ik heb er verder ook geen probleem mee, behalve dan het feit dat het vaak een 'macht der gewoonte' is en vaak dingen omslachtiger maakt dan nodig.

Verwijderd schreef op maandag 05 november 2007 @ 13:49:
Maar to each his own, ik ben nog nooit tegen problemen aangelopen door UNIX timestamp te gebruiken, als jij nog nooit tegen problemen aan bent gelopen door het eigen timestamp formaat te gebruiken dan zijn ze allebei prima toch?

Eensch; ieder z'n meug Het gaat er mij om dat er iig over wordt nagedacht Er wordt gewoon vaak over het hoofd gezien dat die typen überhaupt bestaan (net zoals ik zo vaak zie dat een monetair bedrag in een float wordt opgeslagen terwijl er (vaak, niet altijd) betere typen beschikbaar zijn).

[ Voor 40% gewijzigd door RobIII op 05-11-2007 13:55 ]

[Verwijderd]

Inderdaad, monetaire waardes als float opslaan is vragen om problemen IMHO.

Ik ben ook voorstander voor nadenken, ook al is de conclusie verkeerd, als je erover hebt nagedacht is het niet half zo erg als dat er zomaar iets wordt gedaan.

[Confusion]

Verwijderd schreef op maandag 05 november 2007 @ 13:49:
Zeker in de westerse wereld waar de meeste tijdformaten gebaseerd zijn op de Gregoriaanse kalender, een kalender die zelf al een stapel bugs had waar je U tegen zegt. De UNIX timestamp is een hele absolute manier om tijd weer te geven, dat vind ik er prettig en goed aan.

De Unix timestamp is gerekend vanaf een moment op de Gregoriaanse kalender en heeft dus precies dezelfde problemen.

[Verwijderd]

Confusion schreef op maandag 05 november 2007 @ 14:08:
[...]

De Unix timestamp is gerekend vanaf een moment op de Gregoriaanse kalender en heeft dus precies dezelfde problemen.

Nee dat is dus niet waar.

De Unix timestamp is gerekend vanaf het moment dat volgens de Gregoriaanse kalender zoals vandaag de dag in gebruik wordt aangemerkt als 1-1-1970 0:00 UTC, het gaat dus om dat moment en niet om die tijd.

Mochten er nog meer bugs blijken te zitten in de Gregoriaanse kalender (zoals de schrikkelseconde die we laatst nog hebben meegemaakt) dan heeft dat geen invloed op de UNIX timestamp, het is dan nog steeds het aantal atoomsecondes sinds dat ene moment.

Je hoeft dus nooit correcties door te voeren aan de UNIX timestamp aangezien dat moment een vast moment in de tijd is en atoomsecondes ook een vaste hoeveelheid tijd representeren. Je kunt dus met een hele hoge nauwkeurigheid een moment in de tijd exact vastleggen als UNIX timestamp.

Omdat ieder moment in de tijd ook gerepresenteerd kan worden met een andere kalender maakt het in principe niet meer uit welke kalender de eindgebruiker gebruikt of in welke tijdzone hij zit. Het moment in de tijd wat bedoeld wordt is altijd hetzelfde als UNIX timestamp uitgedrukt.

Mocht bijvoorbeeld nu blijken dat 1-1-1970 eigenlijk 1-1-1969 is omdat ze ooit een jaar misgerekend hebben ofzo (wie weet wat voor gekke zaken ze verzinnen) dan doet dat niets af aan de UNIX timestamp, dan is de UNIX timestamp gewoon vanaf 1-1-1969 in de Gregoriaanse kalender maar ieder moment in de tijd blijft hetzelfde in UNIX timestamp als dat het voorheen was.

[ Voor 12% gewijzigd door Verwijderd op 05-11-2007 14:25 ]

[Confusion]

Verwijderd schreef op maandag 05 november 2007 @ 14:24:
Nee dat is dus niet waar.

Als ik een datum opsla als de string '2007-11-05-14.52.47.000000', dan geef ik ook precies een bepaalde hoeveelheid tijd sinds '1970-01-01-00.00.00.000000'. Het is alleen een andere representatie van die hoeveelheid tijd. We houden er andere meta-informatie op na: ik heb als meta-informatie de definitie van de Gregoriaanse kalender op het moment waarop de datum is opgeslagen nodig. Jij hebt als meta-informatie het gegeven nodig dat de atoomseconde constant is gebleven en die niet (als we toch met far out hypothesen bezig zijn) gedurende 1992 2% korter was.

Als er iets vreemds met de kalender gebeurt, dan moet jij alle libraries aanpassen die gebruikt worden om die timestamp naar een, voor mensen herkenbaar, formaat om te rekenen. Ik moet de data in de database corrigeren. De timestamp is een formaat dat in veel gevallen handiger is, maar omdat de data uiteindelijk altijd voor menselijke gebruik bedoeld is en mensen die rare kalender blijven gebruiken, is het geen absolute oplossing. Zolang de tijdsschaal waarop kalenderveranderingen plaatsvinden langer is dan de tijd waarop mijn data bruikbaar moet zijn, is de Unix timestamp precies even goed als een representatie die bijvoorbeeld iets sneller verschillen in dagen uit kan rekenen dan op grond van doubles mogelijk is.

Overigens was een van die schrikkelsecondes geen bug van de Gregoriaanse kalender, maar van het universum: het is het gevolg van de eindige nauwkeurigheid van de definitie van de atoomseconde: die had in theorie prima zo gedefinieerd kunnen worden dat er in een Gregoriaans jaar precies 365.24258*24*3600 seconden lang was, maar in de praktijk lukt dat niet.

Een ander effect, dat voor meer schrikkelsecondes zorgt, is de vertraging van de aarde, waardoor jaren langer worden: daar heeft iedere denkbare kalender (die cyclisch met betrekking tot dag-nacht en de rondgang rond de zon is) last van en is geen specifiek gebrek van de Gregoriaanse kalender. Schrikkeldagen zijn overigens ook geen bug, maar juist een feature, bedoeld om eerdere kalenders te corrigeren. De bug die de Gregoriaanse kalender heeft, is kleiner dan die van andere kalenders: 1 dag per 3300 jaar.

[ Voor 12% gewijzigd door Confusion op 05-11-2007 15:24 ]

[Verwijderd]

Confusion schreef op maandag 05 november 2007 @ 15:17:
[...]

Als ik een datum opsla als de string '2007-11-05-14.52.47.000000', dan geef ik ook precies een bepaalde hoeveelheid tijd sinds '1970-01-01-00.00.00.000000'. Het is alleen een andere representatie van die hoeveelheid tijd. We houden er andere meta-informatie op na: ik heb als meta-informatie de definitie van de Gregoriaanse kalender op het moment waarop de datum is opgeslagen nodig.

Een ingewikkelde definitie die nog eens regelmatig gewijzigd wordt ook.

Jij hebt als meta-informatie het gegeven nodig dat de atoomseconde constant is gebleven en die niet (als we toch met far out hypothesen bezig zijn) gedurende 1992 2% korter was.

Een simpele definitie die als het goed is nooit gewijzigd wordt, maar nobody is perfect he?

Als er iets vreemds met de kalender gebeurt, dan moet jij alle libraries aanpassen die gebruikt
worden om die timestamp naar een, voor mensen herkenbaar, formaat om te rekenen. Ik moet de data in de database corrigeren.

Het aantal libraries < Het aantal software pakketten gebruik makende van deze library * het aantal regels in de databasen van deze paketten

De timestamp is een formaat dat in veel gevallen handiger is, maar omdat de data uiteindelijk altijd voor menselijke gebruik bedoeld is en mensen die rare kalender blijven gebruiken, is het geen absolute oplossing. Zolang de tijdsschaal waarop kalenderveranderingen plaatsvinden langer is dan de tijd waarop mijn data bruikbaar moet zijn, is de Unix timestamp precies even goed als een representatie die bijvoorbeeld iets sneller verschillen in dagen uit kan rekenen dan op grond van doubles mogelijk is.

Qua snelheid zijn ze gelijk waarschijnlijk, intern kent de CPU alleen bitjes dus het hangt puur af van de efficientie van de library en die zal vergelijkbaar zijn. Ook zijn beide methodes absoluut geschikt, anders zouden ze immers niet gebruikt worden.

Overigens was die schrikkelseconde geen bug van de Gregoriaanse kalender, maar van het universum: het is het gevolg van de eindige nauwkeurigheid van de definitie van de atoomseconde: die had in theorie prima zo gedefinieerd kunnen worden dat er in een Gregoriaans jaar precies 365.24258*24*3600 seconden lang was, maar in de praktijk lukt dat niet. Een ander effect is de vertraging van de aarde, waardoor jaren langer worden: daar heeft iedere denkbare kalender (die cyclisch met betrekking tot dag-nacht en de rondgang rond de zon is) last van en is geen specifiek gebrek van de Gregoriaanse kalender. Schrikkeldagen zijn overigens ook geen bug, maar juist een feature, bedoeld om eerdere kalenders te corrigeren. De bug die de Gregoriaanse kalender heeft, is kleiner dan die van andere kalenders: 1 dag per 3300 jaar.

Ik ben niet gek, de rest van het universum is gek

Maar ik snap wat je wilt zeggen.