Bug when changing timestamp, longstanding

[pol098]

There has been a bug in changing the "modified date" of a file (the date used by default) in many TCMD versions over many years, including the current 9beta15. It's not particularly serious, but as we're in the runup to a new version:

I'm using Win10/64 now, but I doubt that's relevant. Select a file, click Files > Change attributes. Tick Change date/time. If the file date is, say "24 09 2016" it can be changed by overwriting it completely with, say, 12 2 2015" (leading zeroes are ignored and never a problem); after clicking OK the file date shows, as expected, as 12 02 15 (with my settings).

However, if the string "24 09 2016" is edited rather than overwritten, say by positioning the cursor after "09" and backspacing out the day and month, then the remaining " 2016" is edited by insertion to "12 2 2016", the modified date is changed to "12 02 00", i.e. 12 02 2000. In other words, editing the date in this way saves a wrong value. Sometimes editing seems to work, sometimes not, it may depend upon leading zeroes, exactly how editing is done, extra spaces in the string, etc.

If this function is used frequently it's easy to remember always to overwrite the whole date; but it might trip the occasional user.

That's the end of the description; I'll answer the probable question "why would anyone want to change the timestamp"? 1. Because it's there, TCMD supports it. 2. If I, say, download an archive, or a document with the date at the top, the date I downloaded it is irrelevant, and I rarely care about the time. So I very often re-timestamp files with a meaningful date, and set the time to 0 (=00:00:00). The fact that the time is set to zero tells me that I have redated the file meaningfully. (The time may show as 23:00, or as another time with zero minutes, according to summertime and time zone, but the 0h 0m 0s is the tipoff.)

[petermad]

Hmm, I have never noticed that behaviour, and I have now just tried 25 times or more changing the file date in various ways - with or without leading zeros, with mixed leading zeroes (2-04-2016 or 02-4-2016), with different deliminators (- . , : ; \ / and space), with 4 or 2 digits in the year (2016 or 16) and it works as expected every time.

Question: is it always only the year that gets written wrongly as in your example, or can it also be other parts of the date?

Question: do you also have the problem when editing the time?

EDIT: I just noticed that if there are two delimiters before the year (12-2--2016) then the output is 12-02-2000, as in your example. Since you are using spaces as delimiters:

Code: Select all

12 02  2016

I gues that maybe you don't see the extra space.

I also noticed that if I put in wrongly placed delimiters in the year (12-02-20-16) the output is 12-02-2020.

I think that TC should refuse to change the date when there are two or more consecutive delimiters or more than two delimiters in total, rather than making these kind of unexpected changes.

[pol098]

Thanks petermad for response and questions. As it doesn't happen to others, I investigated further (rather than answering questions). I have my system (OpSys+TCMD) set up in a way that displays dates as numbers separated by single spaces "24 09 2016". This is the format both for TCMD date display and entry. I don't think this problem is actually related to editing a date at all; rather it is that if a date has two spaces instead of one, it is not saved correctly. When typing in a date I automatically use a single space; when quickly part-deleting a date and inserting, say, a different day and month of the same year I probably often end up leaving the existing space, and typing an additional one. It would appear that if there are two spaces between month and year, a 20xx year corrupts to "2000". There is no problem with an extra space before the month. In other words, with "b" representing a blank space, a date entered as "24b9bb2016" (whether by editing or clearing and full entry) corrupts the year. "24bb9b2016" works as expected. Entering the date with "/" as separator works. "24/9/2016" and "24--9-2016" also work, if and only if there are no embedded spaces.

This isn't a serious matter, but I'd suggest that it might be worth modifying the date entry routine to trim all non-significant spaces, allowing "24bb9bb2016", "24/b9/2016", etc.

By the way, I don't why I'm using the space-separated numeric format; either a decision, or something I just did, years ago. A fresh installation of TCMD on a VM uses slashes. My system short date format is the non-standard
"dd MMM yy" (24 Sep 16); maybe this changes the separator?

[petermad]

My system short date format is the non-standard
"dd MMM yy" (24 Sep 16); maybe this changes the separator

Yes, TC uses the system format.

[pol098]

My system short date format is the non-standard
"dd MMM yy" (24 Sep 16); maybe this changes the separator

Yes, TC uses the system format.

Thanks again for confirmation. I'd amend my report, though I continue to think this is a (minor) shortcoming of TCMD:

TCMD silently uses a wrong date if a date entered has extraneous embedded spaces (in particular between month and year). This affects changing the timestamp of a file and possibly other date entry functions such as date range in Advanced Search. It is particularly noticeable if the date separator set up in the OpSys is the space character, rather than "/" or "-".

By the way, TC doesn't use the system format as such, just the date separator; in my setup dates show in TC as "26 09 16", and in Explorer as "29 Sep 16".

Best wishes, pol098

[petermad]

By the way, TC doesn't use the system format as such, just the date separator; in my setup dates show in TC as "26 09 16", and in Explorer as "29 Sep 16".

TC cannot show dates with text in the file lists so thats why Sep is changed to 09. BTW It is not just the separator TC gets from the system but also the sequence like 2016-09-26 in Sweden or 9/26/2016 in USA

[pol098]

Thanks again to petermad for clarification. I don't see it as necessary to display dates with text; I simply commented that TC displayed dates differently from, say Explorer, in response to the information that TC got date format information from the OpSys. (If there was a requirement it could easily be added to TC, but it seems pointless). And of course it must get the order from the OpSys, there is no alternative: 12 9 16 vs 9 12 16 vs 16 9 12.

The actual issue with TC, which is minor, is that extraneous spaces in dates entered cause silent data corruption. I have been caught out by this due to careless entry and not checking the result, ending up with recent files dated like "26 09 2000".

A comment unrelated to TC: I personally prefer 2-letter date formats where screen space is tight, as they are more compact, needing no separator: 29Se16, 6 characters, quite clear. Or Tu29Se16. (JaFeMrApMyJnJlAuSeOcNoDe SuMoTuWeThFrSa, or equivalent in other languages). Easy to get used to and take in at a glance. I have deployed these in software that was widely used.

Best wishes

[ghisler(Author)]

The separator doesn't matter, TC will see most non-numeric characters as separators. TC just uses the day - month - year order from the system settings.

But indeed TC only accepts a single separator character between the digits.

[petermad]

But indeed TC only accepts a single separator character between the digits.

Here is the problem - TC does actually accept wrong number of separator characters, in the way that it doesn't give an error message or silently refuses to change the date - TC in some cases change the date wrongly.

[ghisler(Author)]

I have changed that now to accept any number of separator characters which are not numbers. Please try it!

[petermad]

It works fine in TC9b16 when using extra separator chars between day and month and between monts and year

Now, only the problem resists if the format is not followed, by for example by mistake putting a separator character in the middle of the year: 22-12-20-16 (in stead of 22-12-2016) - in this case TC sets the date to 22-12-2020 - I would prefer that TC didn't change the date in such a case.

[ghisler(Author)]

22-12-20-16

22-12-20 is seen as a valid date. -16 is ignored. I want to keep it that way.

[pol098]

I have changed that now to accept any number of separator characters which are not numbers. Please try it!

Having originally reported this issue, I have tried the fixed TCMD 9b16. The specific problem that affected me in real life, saving a date incorrectly if multiple spaces, rather than a single space, are used as separator is resolved. E.g., "2bb10bb2016" (b=blank) now works fine.

Something that could be considered a problem does remain if you go looking for it, though it doesn't affect me; I simply report it in case it is considered relevant. Testing using a fresh installation in a WinXP/32 virtual machine I find that dates entered with slash ("/") as separator and one or more blanks do not register, at least in my setup. E.g. "2/b2/2016", "b2/b5b/2016".

In case it's of any use, I mention that in date entry routines I wrote long ago I simply scanned for numerics; anything with 3 numbers in range, separated by any non-numerics was accepted (with separate provision for month names, 19851225, and even "25 xii 85"). (Though these routines crashed with some consequences when the 2-byte representation I used for dates overflowed more years down the line than I thought they'd be used...)

This matter has never been more than a small niggle in a very useful program, of course.

[ghisler(Author)]

Sorry, I don't understand the problem. Do you want to enter the date as hexadecimal digits? But even, then 2/b2/2016 would be invalid. Currently TC skips these non-numbers, so it reads it as:
2 2 2016

[Hacker]

Christian,
"b" signifies a space in this context (to make multiple consecutive spaces easier to recognize in the post, "bb" instead of " ").

Roman