-
-
Notifications
You must be signed in to change notification settings - Fork 204
-
-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot work out correct format for entering date data. #769
Comments
I have a further problem in the spreadsheet I'm actually working with: I cannot apply the formatting of the date in the previous cell to the new one that I've created. I'm using Alternatively, if I copy the formatting first, then enter the date. This doesn't work either: |
@marrs Im not sure if I understand your problem. Lets say you have this text on A0: If you issue You can then also reformat the numeric value, for instance to 31/12/2022 with: |
Thanks for that explanation. It's helped me understand some of the things I've been seeing. In hindsight I think I've encountered multiple separate and overlapping issues that make this a far more complex bug report than I initially realised! If I was starting again, I might break this into multiple tickets, but then again, there's an overall user experience issue here that I want to get across and keeping these issues together helps me do that. That said, this is a large ticket now, and I apologise for that. It's not my intention to overwhelm you and I hope that I've done my part to be as clear and concise as is necessary. 1. Actual bug:
|
I think the confusion seems to be coming from the assumption that these 2 steps are the same. In Excel (afaik), this action is carried out in just one step, declaring what date format you want, and then Excel is left with converting the date into a timestamp. Here, you declare what the format is so that it can be converted to a numeric value and then what format you want to display. This also confused me at the beginning. |
@andmarti1424 did you manage to digest this ticket at all? It would be good to know at least which of these issues can be confirmed as bugs and which need further discussion |
Hello. Some, I still have to check all of the cases you reported. |
@marrs And yes, issue 2 seems something I have to fix. |
I'll try setting it to a positive value and see if that fixes the issue. If it does then I'll submit a new bug report with the additional info.
I'm not sure what you mean by using date functions. I enter the date as a string and then try to convert it to a date value using |
@marrs I meant if you use any of the functions describes on "Built-in Date and Time Functions" section of doc. |
@marrs Regarding |
@marrs Regarding 3, its true. |
@marrs Could you take a look at the change? |
Sorry, @andmarti1424, I didn't see your initial reply. I'm busy for the next week but I'll try and look at this over the weekend. Otherwise I'll get to it towards the end of the month. |
@andmarti1424 dev branch fixes items 2 & 3. |
@andmarti1424 Setting tm_gmtoff had no effect on item 1. I ran the spreadsheet with commands |
Just entering dates. I've not tried any of those functions before |
Regarding number 1, you have to do like this for instance: |
The treatment of dates in sc-im is causing me confusion. I don't know if this is a bug or intended behaviour, but it's definitely impeding my ability to enter data.
I had to mess around in a small spreadsheet to understand what was going on. I've copied the file data for that spreadsheet below. It contains 2 columns. The column on the left contains a list of unformatted date values entered as right-aligned text, while the column on the right shows the corresponding results of formatting those values with
C-d
.You can see that the interpretation of the values in the 1st two rows is completely nonsensical. The third row seems to have truncated the year and the fourth finally gets it right (I think).
It looks like the date has to be entered in the format of
%d/%m/%y
in order to be interpreted correctly. So if I add the date with>2022/12/31
, which is the preferred format according to the docs, this doesn't work at all. If I add the date as>31/12/2022
, this also fails. Likewise for the US style,>12/31/2022
.This is very confusing behaviour and there's no feedback from the UI as to what is going on.
None of the formats used to enter the date is ambiguous. It's quite clear for each of them which part must be date, which must be month, and which must be year. I would suggest therefore that the date interpreter should be able to work out that a number greater than 12 is not a month and that a 4 digit number must be a year and reconstruct the date appropriately.
Obviously a value such as
>12/12/12
is ambiguous, but a message from the programme saying how that date has been interpreted would be fine by me.Also, I found the documentation to be misleading. It gives the impression that a UK format should not be used but it seems from my experimenting that in fact it should be, at least on my machine.
The text was updated successfully, but these errors were encountered: