Created attachment 201899 [details] Screenshot_conversion table Bonjour le problème que je vous présente: dans le logiciel LIBREOFFICE (et pas que celui-là) il y a possibilité de conversion d'un nombre en date (et inversement) mais il ya un différence entre BASE et CALC voici un petit tableau qui est beaucoup plus parlant qu'un long discours en Gros la conversion du zéro(0) est ok dans le module CALC la suite est Bonne dans BASE la conversion du zéro(0) est ok = 30/12/1899 puis la conversion du un(1) n'est plus bonne = 29/12/1899 puis le deux(2) est donc converti avec deux jours d'écart = 30/12/1899 que pouvez vous faire s'il vous plait Hello, The problem I'm presenting to you: In the LIBREOFFICE software (and not only that one), it's possible to convert a number into a date (and vice versa) But there's a difference between BASE and CALC. Here's a small table that speaks volumes. Basically, the conversion of zero (0) is OK. In the CALC module, the rest is OK. In BASE, the conversion of zero (0) is OK = 12/30/1899. Then the conversion of one (1) is no longer OK = 12/29/1899. Then the two (2) is therefore converted with a two-day gap = 12/30/1899. What can you do, please?
(In reply to Tomaz from comment #0) > Here's a small table that speaks volumes. :-) Maybe; but when I tried to check how you did your conversion in Base, that table kept silent ;-) An ODB would be nice.
Created attachment 201901 [details] Copie écran 01
Created attachment 201902 [details] Copie écran N°2
Created attachment 201903 [details] la Base de données exemple
Bonjour en complément de mon premier message j'ai fait plusieurs essais différents et finalement cela montre un inconstance dans les conversion DATE -> INTEGER et INTEGER -> DATE la BDD en exemple contient deux Tables, l'une au format INTEGER, l'autre au format DATE sur chacune des Tables je fait une requête qui montre simplement la même colonne deux fois, à vous de changer le format d'affichage de la deuxième colonne et là .... Surprise deux numéros différents pointent sur la même date ET la même date apparait dans la Table 2 en tant que Primary Key ???? je vous laisse regarder, personnellement c'est beaucoup trop compliqué pour moi merci pour votre implication Hello, In addition to my first message, I ran several different tests, and ultimately, it shows an inconsistency in the DATE -> INTEGER and INTEGER -> DATE conversions. The example database contains two tables, one in INTEGER format, the other in DATE format. For each table, I run a query that simply displays the same column twice. It's up to you to change the display format of the second column. And then... Surprise! Two different numbers point to the same date AND the same date appears in Table 2 as the Primary Key. I'll let you take a look; personally, it's way too complicated for me. Thank you for your help.
(In reply to Tomaz from comment #5) > And then... Surprise! Two different numbers point to the same date AND the > same date appears in Table 2 as the Primary Key. No these are not same date. You may want to show all four year's digits.
(In reply to Mike Kaganski from comment #6) > (In reply to Tomaz from comment #5) > > And then... Surprise! Two different numbers point to the same date AND the > > same date appears in Table 2 as the Primary Key. > > No these are not same date. You may want to show all four year's digits. You're right
Created attachment 201905 [details] BDD DATE Nouvelle BDD
Created attachment 201906 [details] How to build the table
Created attachment 201907 [details] What's the f...k
je me suis mal exprimé mais voici une petite idée de mon désarroi faite une base de données avec un champs DATE mettez lui une condition du genre je veux que par défaut la date est le 19/11/1969 (qui correspond au 25526) et là .... surprise soit vous avez une date décalée de 2 jours soit vous avez une réponse non compréhensible I expressed myself poorly, but here's a small idea of my dismay. Create a database with a DATE field. Give it a condition like "I want the default date to be 11/19/1969 (which corresponds to 25526). And then... surprise, either you get a date that's off by 2 days or you get an incomprehensible answer.
I don't see what you see. But can you test with a new version, e.g. 25.2.5?
Yes i tested it with the newest version and it's the same i don't inderstand
Aha. So the problem is the default value for a date column; and the table that speaks volumes was a red herring; as usual, a clear "I do this, see this, and expect this" is much better. Steps 1: 1. In your table design view, type any unambiguous date (preferably in ISO format, to avoid ambiguities imposed by stubborn 2-digit year formats, like 2025-07-19); 2. Click Save in the toolbar; 3. Check that the date is changed to a different date. Steps 2: 4. With some date set as the default, open the table, and check the date shown in the new record. I don't know how step 4 is actually expected to work - but steps 1 - 3 are definitely a bug.
Created attachment 201908 [details] not yet Merci beaucoup mais il y a bien un défaut même en appliquant ce process il reste encore que si la date par défaut est au bon format 1969-11-19 elle se transforme tout de suite en 1969-11- je m'arrache les cheveux car la seule réponse serait de ne pas mettre de contrainte ? Thank you very much, but there is definitely a flaw. Even if you apply this process, the default date is still in the correct format, 1969-11-19, but it immediately changes to 1969-11. I'm tearing my hair out because the only solution would be to not set any constraints.
read 1969-11-23
(In reply to Tomaz from comment #15) Did you read what I wrote? I said: "3. Check that the date is changed to a different date", and "but steps 1 - 3 are definitely a bug". What are you trying to say?
https://gerrit.libreoffice.org/c/core/+/188091 https://gerrit.libreoffice.org/c/core/+/188092 https://gerrit.libreoffice.org/c/core/+/188093
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/060775489a42d5489417b8a5c29c8f0b4006f796 tdf#167591: Only apply date correction, when sDefault wasn't date string It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5b808448dc79e996efa7cb5082145d4e5803daa6 Related: tdf#167591 Make STANDARD_DB_DATE more standard It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3b22e7c3aa0e601e5fae4716e4e354f07e07b05f tdf#167591: Convert date string to date early It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 102945 has been marked as a duplicate of this bug. ***
*** Bug 122140 has been marked as a duplicate of this bug. ***
*** Bug 152021 has been marked as a duplicate of this bug. ***
This fix also fixes bug 96190 and part of bug 88560. Could it be back ported to LO 25.8.?
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/ff73678db107abc1038cfe396e5cd9350e8d7a3c tdf#167591: Only apply date correction, when sDefault wasn't date string It will be available in 25.8.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/86c9b2166ab66882563839f06a8478b85274b109 Related: tdf#167591 Make STANDARD_DB_DATE more standard It will be available in 25.8.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/e6f843c1c5c2cb075ff0ae358735c5801e56f51f tdf#167591: Convert date string to date early It will be available in 25.8.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.