Page 1 of 1

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

Posted: 2021-01-01, 17:02 UTC
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.

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

Posted: 2021-01-01, 17:33 UTC
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.

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

Posted: 2021-01-01, 19:50 UTC
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.

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

Posted: 2021-01-01, 21:02 UTC
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

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

Posted: 2021-01-04, 15:25 UTC
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.

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

Posted: 2021-01-04, 17:39 UTC
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

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

Posted: 2021-01-07, 16:51 UTC
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.

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

Posted: 2021-05-30, 04:52 UTC
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.

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

Posted: 2022-01-07, 05:55 UTC
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

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

Posted: 2022-01-07, 11:53 UTC
by Hacker
dindog,
Well, the grey frame around the control is a little bit more faded.

Roman

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

Posted: 2022-01-07, 13:10 UTC
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

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

Posted: 2022-01-07, 23:11 UTC
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.