Created attachment 133960 [details] Sample database file To demonstrate this feature open the form in the attachment. Click on the Date/time (Time) field (right most field) in the 4th line in either Table Control, to enter a new record. Enter a time of 4:00. Then try to move the cursor up or down and you can't. This doesn't happen in any of the other fields. What I would expect to happen should be similar to what happens when you first add a date into a new record in the Date/time (Date) field. In that case Date/time (Time) is set to 0:00. So what I would expect to happen is that Date/time (Date) should get set to a null or zero date when the Date/time (Time) is entered first. I understand that this Date/Time business is sort of funny, having to have two fields to support one record field. Once data is entered into either of these two field, then the other field also needs to become non-null, so that's the reason for the zeros. Idea: Probably it would be better to just have a Table Control field type called simply Date/Time (rather than Date/time (Date) + Date/time (Time) ). Enter anything looking like a date or time in it and it sets what it can. In other words, if you enter 3:00 it's sets the time only, and the date is left ambiguous, or possibly to the date default. If you set the field to 1/1/1 then only the date is set and the time is set to 0:00.
Created attachment 133961 [details] Sample database file This *.odb replaces the *.odt file which was accidentally uploaded.
Created attachment 133962 [details] Error message I sometimes get with this issue Also at first I get this error message. Later this message does not display but the edit hangs until either the new record is canceled with escape, or you move left and set to the date to something like 1/1/1. What I would expect to happen: When I enter a time, simply enter the time. If there is no date then don't enter the date, or use the default if available, or even just use junk or zeros. Why? So I can use time and time alone in a Date/Time field, and so I can use date and date alone in a Date/Time field. Why? For compatibility with data bases which support Date/Time, or Timestamps, but don't support the newer Time, or Date fields. ___________________________________ In my particular case, and as I transition to LO from Access, I have a shared MySQL data base which both front ends need to be able to connect to. Access is gagging on Time fields. LO is gagging on Date/Time fields. I can't fix Access, but we can fix LO. Surely there must be others who need to easily input date and/or time in a field to produce a Date/Time. I know using Date/Time is not the most efficient when only using it for Date or Time and not both, but sometimes for compatibility and simplicity it is just better to do it this way. Grateful for your work on LO.
Yep, I got the error. Win 7 Pro 64-bit Version: 5.4.0.0.alpha1+ (x64) Build ID: d02d52887678cd3d518c19a235bc443c292b3041 CPU threads: 4; OS: Windows 6.1; UI render: default; TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2017-05-01_22:53:14 Locale: fi-FI (fi_FI); Calc: CL
With LO Debian package 5.4.4.2 or with master sources updated yesterday, I don't reproduce this. I opened the form, put "4:00" on fourth line of the first table on Date column, then could move the cursor with keys. I noticed that "4:00" was automatically replaced by "04:00" and the ID automatically filled. Buovjaga: do you still reproduce this with a recent LO version?
(In reply to Julien Nabet from comment #4) > With LO Debian package 5.4.4.2 or with master sources updated yesterday, I > don't reproduce this. > > I opened the form, put "4:00" on fourth line of the first table on Date > column, then could move the cursor with keys. > I noticed that "4:00" was automatically replaced by "04:00" and the ID > automatically filled. > Buovjaga: do you still reproduce this with a recent LO version? @Julien, When you say, "... the first table on Date column,..." did you mean the Date/Time (Date) column, or the Date/Time (Time) column? This bug report was for the Date/Time (Time) column. But if 4:00 is put into the Date/Time (Date) column it doesn't make sense, and I actually would expect an error, but I'm not seeing one. (I guess I might also have to add that as a separate bug. :-) Just a few minutes ago I tested this on the following versions: 5.4.3.2 - can't move up or down without error. 5.4.4.2 - can't move up or down without error. 6.0.0.0.beta2 - can't move up or down without error. 6.0.0.2 - can't move up or down without error. So, unfortunately I don't see any progress yet. Thanks _______________________ OS: Debian 9.3 (x86-64); Cinnamon: 3.2.7; Linux Kernel: 4.9.0-5-amd64; Processor: Intel Core 2 Duo P8800; Graphics Card: AMD/ATI RV710/M92 Mobility Radeon HD 4530/4570/545v
(In reply to Howard Johnson from comment #5) > ... > did you mean the Date/Time (Date) column, or the Date/Time (Time) column? > ... I'm very sorry, you're right, I was on the wrong column (dumb me!). I got each time the error message you attached.
@Julian, No worries. It's hard not to be human. FTI, I also just tested this on 6.1.0.0.alpha0+ (from a build I did last night) and it also gets stuck there too. (I had intended this to be in my last comment, but my human part got in the way again.)
I submitted a patch to review here: https://gerrit.libreoffice.org/#/c/48665/ Lionel: don't hesitate to comment on bugtracker or on gerrit. Perhaps the patch is a bit naive.
(In reply to Julien Nabet from comment #8) > I submitted a patch to review here: > https://gerrit.libreoffice.org/#/c/48665/ Patch looks good. If no date is entered, it puts 30 December 1899. A small refinement on that would be to put the currently configured null date. But actually, I would do something different: I would put _today_'s date. In the same way that 25/12" is understood as 25 December of the CURRENT YEAR, if only a time is entered, it is that time TODAY. That's just my opinion, you can commit your patch as is if you think 1899-12-30 is better.
(In reply to Lionel Elie Mamane from comment #9) > (In reply to Julien Nabet from comment #8) > > I submitted a patch to review here: > > https://gerrit.libreoffice.org/#/c/48665/ > > Patch looks good. If no date is entered, it puts 30 December 1899. A small > refinement on that would be to put the currently configured null date. > > But actually, I would do something different: I would put _today_'s date. In > the same way that 25/12" is understood as 25 December of the CURRENT YEAR, > if only a time is entered, it is that time TODAY. That's just my opinion, > you can commit your patch as is if you think 1899-12-30 is better. Thank you for your feedback. Since I don't know: - how to indicate that Y/M/D with 0/0/0 corresponds to null date - how to retrieve today's date (which would be indeed better but the same thing should be done too in Table and Query parts then) let's push the patch as it is and if someone wants to improve the situation, I suppose he/she won't hesitate :-)
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a30652295be09afdbba707ce13d0a03e22c4e7a3 tdf#108473: don't let empty date in datetime in forms It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
To avoid to wait for future 6.1, I cherry-picked it the patch on 6.0 branch for review: https://gerrit.libreoffice.org/#/c/48692/ I don't think it worths it for 5.4 branch.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b34ddf572bd5dab6173bf7daf6341d3f0f74535a&h=libreoffice-6-0 tdf#108473: don't let empty date in datetime in forms It will be available in 6.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tested in 6.0.1. Thanks for fixing this Julian.