The 17th Century '1601' Calendar Wrap-around Problem

Please report only one bug per message!

Moderators: white, Hacker, petermad, Stefan2

Post Reply
User avatar
Phred
Senior Member
Senior Member
Posts: 375
Joined: 2009-06-16, 15:24 UTC
Location: SEAu

The 17th Century '1601' Calendar Wrap-around Problem

Post by *Phred »

I seem to have encountered a calendar calculation problem when re-dating some graphics files. I'm getting 1601 as the suggested year for use - requiring scrolling through a few centuries to get the the beginning of the second decade of this century. Or typing it in.
https://ibb.co/ZHmn4P1
Two computers so far.

I see it also when I choose the thumbnails expansion to display a date together with, say, the thumbnail's filename.
[no graphic yet]

Could something serious be going on with TC's move into 2021?

So many graphics files now don't carry any extra - Exif - data, WhatsApp image downloads, for instance. I find I'm doing a lot of 'date work'.


I note that while TC's tc.writetime is strictly hh:mm:ss - tc.writedate is, say, YYYY-MM-DD hh:mm:ss - and that plays havoc when manipulating writedate creationdate accessdate exifdate / times.
It requires a 'proxy' of using createtime, being forced to accept writedate's zeroing of writetime, and taking the temporarily stored createtime and using it for writetime.
But that's for another thread.
Last edited by Phred on 2021-01-01, 19:58 UTC, edited 1 time in total.
Regards, PhredE
Licence holder since 1999
Awaiting a $D donors-token for the title-bar so we can display that we have donated further.
User avatar
Horst.Epp
Power Member
Power Member
Posts: 6429
Joined: 2003-02-06, 17:36 UTC
Location: Germany

Re: The 17th Century '1601' Calendar Wrap-around Problem

Post by *Horst.Epp »

Phred wrote: 2021-01-01, 17:02 UTC I seem to have encountered a calendar calculation problem when re-dating some graphics files. I'm getting 1601 as the suggested year for use - requiring scrolling through a few centuries to get the the beginning of the second decade of this century. Or typing it in.
https://ibb.co/ZHmn4P1
Two computers so far.

I see it also when I choose the thumbnails expansion to display a date together with, say, the thumbnail's filename.
[no graphic yet]

Could something serious be going on with TC's move into 2021?

So may graphics files now don't carry any extra - Exif - data, WhatsApp image downloads, for instance. I find I'm doing a lot of 'date work'.


I note that while TC's tc.writetime is strictly hh:mm:ss - tc.writedate is, say, YYYY-MM-DD hh:mm:ss - and that plays havoc when manipulating writedate creationdate accessdate exifdate / times.
It requires a 'proxy' of using createtime, being forced to accept writedate's zeroing of writetime, and taking the temporarily stored createtime and using it for writetime.
But that's for another thread.
Whatever problems you see in your environment they are not common or with the new year.
I renamed many new and old photos and Whatsapp images from today (2021) and last year (2020) without any problem in TC and other tools.
Renaming based on Exif creation date is the method which works without problems with files from this year (2021) and any other.
I also updated directory time stamps based on file dates of their content without any problems.
So I guess you are alone with this problem.
Windows 11 Home x64 Version 23H2 (OS Build 22631.3296)
TC 11.03 x64 / x86
Everything 1.5.0.1371a (x64), Everything Toolbar 1.3.2, Listary Pro 6.3.0.69
QAP 11.6.3.2 x64
User avatar
Phred
Senior Member
Senior Member
Posts: 375
Joined: 2009-06-16, 15:24 UTC
Location: SEAu

Re: The 17th Century '1601' Calendar Wrap-around Problem

Post by *Phred »

That might be a little premature, Horst.
I agree that TC can do what it's done for you, for me.
Have you tried, however, the TC 'TC plug-in' under the + control in Attribute changing - as per the graphic?
And the TC + in setting a date for thumbnails?

My graphic's not a mock-up, of course.
Regards, PhredE
Licence holder since 1999
Awaiting a $D donors-token for the title-bar so we can display that we have donated further.
User avatar
HolgerK
Power Member
Power Member
Posts: 5406
Joined: 2006-01-26, 22:15 UTC
Location: Europe, Aachen

Re: The 17th Century '1601' Calendar Wrap-around Problem

Post by *HolgerK »

2Phred

The current behavior is:
a) if the "value field" is empty and only one file is selected: [>>] is initialized with the "plugin-property-value" from the the selected file
b) if the "value field" is empty and more then one file is selected: [>>] is initialized with the current date time
c) if the "value field" is not empty (regardless of how many files are selected): [>>] tries to convert the "value field" into a date (allowing to edit the current "value field" date)
"[=tc.creationdate]" is in no case a valid date format (->fallback to the first valid date for ntfs - dates).

You may rethink your expectation that the initial date for the [>>]-button should be taken indirectly from a file's creation date (or any other date from any other content plugin), which obviously is impossible if more than one file is selected.
It's not a bug, but may be a feature request only in case of single file selection.

Workaound:
- starting with: tc.creationdate = ""
- press [>>] and edit the value field to your needs
- change the destination field from creationdate to writedate: tc.writedate = "<edited creation date>"

Regards
Holger
Make our planet great again
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48012
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Re: The 17th Century '1601' Calendar Wrap-around Problem

Post by *ghisler(Author) »

1601 is the first year supported by the Windows date format. It means that you have a timestamp of zero for some unknown reason. either the file system doesn't support the "creation time" field, or it wasn't set.
Author of Total Commander
https://www.ghisler.com
User avatar
HolgerK
Power Member
Power Member
Posts: 5406
Joined: 2006-01-26, 22:15 UTC
Location: Europe, Aachen

Re: The 17th Century '1601' Calendar Wrap-around Problem

Post by *HolgerK »

@ghisler(Author)

Steps to reproduce:
1. mark only a single file
2. "Files-> Change Attributes.."
3. [x] "Change Plugin Attributes"
4. [More attributes]: "tc.writedate"
5. Press [+] and select "[=tc.creationdate]" as Value
6. Press [>>] to edit the Value
-> 1601-01-01 00:00:00

I guess that Phred's expectation is that the value editor should come up with the creation date of the marked file in case of non empty value field and the value field points to a valid plugin attribute.

Regards
Holger
Make our planet great again
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48012
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Re: The 17th Century '1601' Calendar Wrap-around Problem

Post by *ghisler(Author) »

Ah, I see: >> will parse the data in the edit box, and since it doesn't contain a valid date, it will set the date value to zero. >> doesn't evaluate plugin fields here, because they are different for each file.
Author of Total Commander
https://www.ghisler.com
User avatar
Phred
Senior Member
Senior Member
Posts: 375
Joined: 2009-06-16, 15:24 UTC
Location: SEAu

Re: The 17th Century '1601' Calendar Wrap-around Problem

Post by *Phred »

Yes, that was my thinking. '1601' seemed to come right out of 'nowhere', making no sense at all, and that suggested to me, and possibly others, that there was an underlying flaw in the system.
Thx all.
Regards, PhredE
Licence holder since 1999
Awaiting a $D donors-token for the title-bar so we can display that we have donated further.
User avatar
dindog
Senior Member
Senior Member
Posts: 315
Joined: 2010-10-18, 07:41 UTC

Re: The 17th Century '1601' Calendar Wrap-around Problem

Post by *dindog »

just some off-topic
i love the idea of "dark theme", my cell phone have a dark theme, but Win10's dark theme is just unuseable. Like the screen shot of Phred, there is no way that user can tell the edit box or listbox control is enable or not by visual.
https://ibb.co/M9vZYhQ
User avatar
Hacker
Moderator
Moderator
Posts: 13041
Joined: 2003-02-06, 14:56 UTC
Location: Bratislava, Slovakia

Re: The 17th Century '1601' Calendar Wrap-around Problem

Post by *Hacker »

dindog,
Well, the grey frame around the control is a little bit more faded.

Roman
Mal angenommen, du drückst Strg+F, wählst die FTP-Verbindung (mit gespeichertem Passwort), klickst aber nicht auf Verbinden, sondern fällst tot um.
User avatar
HolgerK
Power Member
Power Member
Posts: 5406
Joined: 2006-01-26, 22:15 UTC
Location: Europe, Aachen

Re: The 17th Century '1601' Calendar Wrap-around Problem

Post by *HolgerK »

2dindog
You can modify Configuration -> Options... -> Color -> Other: -> Dark Mode: -> Text color to show the active elements slightly different than the inactive elements: e.g. a blue color tone (RGB: 64,128,192) instead of grey, or a lighter grey tone (RGB: 144,144,144)

Regards
Holger
Make our planet great again
User avatar
petermad
Power Member
Power Member
Posts: 14700
Joined: 2003-02-05, 20:24 UTC
Location: Denmark
Contact:

Re: The 17th Century '1601' Calendar Wrap-around Problem

Post by *petermad »

HolgerK wrote: 2022-01-07, 13:10 UTC 2dindog
You can modify Configuration -> Options... -> Color -> Other: -> Dark Mode: -> Text color to show the active elements slightly different than the inactive elements: e.g. a blue color tone (RGB: 64,128,192) instead of grey, or a lighter grey tone (RGB: 144,144,144)

Regards
Holger
You can set the color for Highlighted elements - an Active element is not necessarily highlighted. And anyway the problem was to distinguish disabled elements.
License #524 (1994)
Danish Total Commander Translator
TC 11.03 32+64bit on Win XP 32bit & Win 7, 8.1 & 10 (22H2) 64bit, 'Everything' 1.5.0.1371a
TC 3.50b4 on Android 6 & 13
Try: TC Extended Menus | TC Languagebar | TC Dark Help | PHSM-Calendar
Post Reply