Author |
Topic: FILES dependence on locale settings (Read 380 times) |
|
Richard Russell
Administrator
member is offline
 
Posts: 1348
|
 |
FILES dependence on locale settings
« Thread started on: Apr 1st, 2017, 10:09am » |
|
Somebody has pointed out that FILES will not correctly format the date string if your locale is configured not to add a leading zero on the day or month figure. So for example if your regional settings specify the Short Date format as 'd/M/yy' LBB will report the date incorrectly if the day or month figure is less than 10.
To fix this LBB would need to adapt to all the possible different date formats in use around the world. I will look into this if and when there is another release, but it would not be trivial!
Richard.
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: FILES dependence on locale settings
« Reply #1 on: Apr 2nd, 2017, 9:50pm » |
|
on Apr 1st, 2017, 10:09am, Richard Russell wrote:| Somebody has pointed out that FILES will not correctly format the date string if your locale is configured not to add a leading zero |
|
The person who reported this bug is not happy! Because this particular feature works 'properly' in LB 4 (albeit that the Help file doesn't actually specify what the date string format should be) he seems to think that I should work towards trying to fix it in LBB immediately. 
To help with analysing this issue can I ask that people in different parts of the world report how FILES formats the date in LB4 and LBB currently, given the settings for their locale. In the UK both report the date as dd/mm/yy.
Edit: The person who reported the bug gets dd.mm.yy in LB4.
Richard.
|
|
|
|
RobM
Junior Member
member is offline
Posts: 91
|
|
Re: FILES dependence on locale settings
« Reply #2 on: Apr 2nd, 2017, 10:01pm » |
|
USA
02/19/16 01:03:30 AM (LB)
2/19/16 1:03:30 AM (LBB)
Code:
dim info$(10, 10)
files DefaultDir$, info$()
print info$(1, 2)
end |
| « Last Edit: Apr 2nd, 2017, 10:04pm by RobM » |
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender: 
Posts: 210
|
|
Re: FILES dependence on locale settings
« Reply #3 on: Apr 3rd, 2017, 08:25am » |
|
XP SP3 locale set to Russian (dd.mm.yyyy format)
make a file with given date
Code:touch -t02/01/17 01022017.txt
(I don't even know where touch is - too many old compilers installed)
check this file
Code: dim info$(10, 10)
files DefaultDir$, "C:\wrk\C\01022017.txt", info$()
print info$(1, 2)
end
JB1.01
Code:
LB3.06
Code:
|
| « Last Edit: Apr 3rd, 2017, 08:26am by tsh73 » |
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: FILES dependence on locale settings
« Reply #4 on: Apr 3rd, 2017, 2:54pm » |
|
The examples have allowed me to determine that the bug in LBB is not, as I had thought, triggered by a single-digit month or day number but by the convention in Boznia, Croatia and Herzegovina of adding a trailing 'dot' after the year number. So for example today's date would be '3.4.2017.' rather than '3.4.2017'. The code in LBB assumes that the last 4 digits of the date string will be the year, so the presence of this final dot causes it to strip out the wrong characters when converting a 4-digit year to a 2-digit year!
It is worth noting that because Liberty BASIC and Just BASIC format the date string depending on the region (e.g. DMY in Europe and MDY in the USA) it would be difficult to make use of it for any purpose other than to display it to the user. For example using that string to sort the file list in date order would not work, straightforwardly, if the program is intended to be run in different regions/locales.
So, that being the case, perhaps it doesn't really matter if LBB formats the date differently from LB/JB, so long as it is a 'correct' representation of the date for the relevant region. The most straightforward fix for the bug would be for LBB to use whatever 'short date' format is selected in Control Panel, including all four digits of the year if present.
What do you think?
Richard.
|
|
|
|
Rod
Full Member
member is offline
Gender:
Posts: 110
|
|
Re: FILES dependence on locale settings
« Reply #5 on: Apr 3rd, 2017, 3:39pm » |
|
Since ordering files requires YYYY/MM/DD/HH/MM/SS and requires leading zeros that would be my preference, leading zeros. That allows simple comparison rather than more complex parsing.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: FILES dependence on locale settings
« Reply #6 on: Apr 3rd, 2017, 4:39pm » |
|
on Apr 3rd, 2017, 3:39pm, Rod wrote:| Since ordering files requires YYYY/MM/DD/HH/MM/SS and requires leading zeros that would be my preference, leading zeros. That allows simple comparison rather than more complex parsing. |
|
I agree, but would it be acceptable to make such a drastic and incompatible change at this stage? Perhaps a better approach would be to introduce a new column in the array, e.g. info$(n,4) containing an ordered timestamp specifically for the purpose of sorting etc.
We will probably never know, but I wonder whether LB/JB using a region-dependent and non-sortable date string format was a deliberate decision by Carl or an 'accident' arising from the use of some intrinsic SmallTalk function, perhaps.
Richard.
|
|
Logged
|
|
|
|
SarmedNafi
Junior Member
member is offline
Posts: 93
|
|
Re: FILES dependence on locale settings
« Reply #7 on: Apr 4th, 2017, 02:16am » |
|
In Baghdad we use the format: dd/mm/yyyy
The following code:
dim info$(10, 10)
files DefaultDir$, info$()
print info$(1, 2)
end
Produce under LBB and LB:
04/04/17 04:46:10 AM
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: FILES dependence on locale settings
« Reply #8 on: Apr 4th, 2017, 3:55pm » |
|
on Apr 3rd, 2017, 4:39pm, Richard Russell wrote:| Perhaps a better approach would be to introduce a new column in the array, e.g. info$(n,4) |
|
Can anybody think of a disadvantage (compatibility implications or otherwise) of doing this? The only negative consequence would seem to be the use of additional memory for the extra timestamp data, which of course could conceivably make the difference between a program running or not, but being that close to running out of memory seems improbable.
Richard.
|
|
Logged
|
|
|
|
|
