LB Booster
IDE and Compiler >> Compiler >> FILES dependence on locale settings
http://lbb.conforums.com/index.cgi?board=compiler&action=display&num=1491041366
FILES dependence on locale settings
Post by Richard Russell 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.
Re: FILES dependence on locale settings
Post by Richard Russell 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. sad

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.
Re: FILES dependence on locale settings
Post by RobM 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
Re: FILES dependence on locale settings
Post by tsh73 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:
01.02.17 11:19:14

LB3.06
Code:
01.02.17 11:19:14
Re: FILES dependence on locale settings
Post by Richard Russell 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.
Re: FILES dependence on locale settings
Post by Rod 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.
Re: FILES dependence on locale settings
Post by Richard Russell 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.
Re: FILES dependence on locale settings
Post by SarmedNafi 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
Re: FILES dependence on locale settings
Post by Richard Russell 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.