Bug with FolderItem.CreationDateTime and FolderItem.ModificationDateTime

The following code is supposed to set the creation and and modification dates of a file to January 1st, 2020, 12:00:00am. However, the resulting file has December 31st, 2019, 11:00:00pm as the creation and modification dates. Why is that?

[code]dim f As new FolderItem(“Test File.txt”)
if f <> nil then
dim t as TextOutputStream
t = TextOutputStream.Create(f)
t.Write “This is a test”
t.Close
end if

dim d as new DateTime(2020,1,1,0,0,0)

f.CreationDateTime = d
f.ModificationDateTime = d[/code]

Interesting. I just tried it on my Windows 10 system and see what you are seeing. However, if I break immediately after the f.ModificationDateTime = d statement and look at the folderitem f in the debugger, the creation datetime and the modification datetime seem correct. It’s almost like the handoff to the OS is getting messed up.

Changing the datetime specification to

Dim d As New DateTime (2020, 1, 1, 1, 0, 0)

yields a modification date of 1/1/2020 12:00 AM, and changing the datetime specification to

Dim d As New DateTime (2020, 1, 1, 6, 0, 0)

yields a modification date of 1/1/2020 5:00 AM

It’s as if the Hour parameter is 1-based while the Minutes are 0-based. Or perhaps the issue is Daylight Saving Time.

Changing it to

Dim d As New DateTime (2020, 1, 1, 1, 0, 0, 0, timeZone.Current)

doesn’t help either.

I just tried and seeing same results as Roger and Dale

Win 10 Xojo 2019R3.1

And the same on macOS 10.15 / Xojo 2019r3.1.
Even with the “API 1” Date:

dim d as new Date(2020,1,1,0,0,0) f.CreationDate = d f.ModificationDate = d
Same Code, same macOS, but Xojo 2019r1.1: as expected.
So definitely yet another regression in FolderItem (which has been rewritten for API 2).

did you, or anyone, file a bug report about this ?
all these little glitches really take a toll

I guess the other question is does it work properly if you just use the API 1.0 form in 2019r3.1 ?

[quote=484082:@Norman Palardy]did you, or anyone, file a bug report about this ?
all these little glitches really take a toll

I guess the other question is does it work properly if you just use the API 1.0 form in 2019r3.1 ?[/quote]
Nope. Here is the old fashioned way, and it produces the same result:

[code]dim f As new FolderItem(“Test File.txt”)
if f <> nil then
dim t as TextOutputStream
t = TextOutputStream.Create(f)
t.Write “This is a test”
t.Close
end if

dim d as new Date
d.Year = 2000
d.Month = 1
d.Day = 1
d.Hour = 0
d.Minute = 0
d.Second = 1

f.CreationDate = d
f.ModificationDate = d

[/code]

I believe you’re right. Setting it to a date after March 8th doesn’t produce the -1hr offset.

[quote=484085:@Roger Meier]Nope. Here is the old fashioned way, and it produces the same result:

[code]dim f As new FolderItem(“Test File.txt”)
if f <> nil then
dim t as TextOutputStream
t = TextOutputStream.Create(f)
t.Write “This is a test”
t.Close
end if

dim d as new Date
d.Year = 2000
d.Month = 1
d.Day = 1
d.Hour = 0
d.Minute = 0
d.Second = 1

f.CreationDate = d
f.ModificationDate = d

[/code][/quote]

ah yeah I’ve run into this

Constructing a date doesnt give you the GMT offset that was in effect on that day & time
It gives you TODAYS gmt offset
Seems the new DateTime does that as well - which is horribly wrong
That should be reported as a bug if it hasnt been already

Now, the question is, what happens if today’s date weren’t during daylight savings, would there still be a -1hr offset? Or furthermore, what if today’s date weren’t during DST, but the date I’m trying to set the file date to is during DST, would that result in a +1hr offset?
So, if this offset is in fact due to the DST difference between the system date and the intended file dates, then code such as this may be a workaround:

dim today as DateTime = DateTime.Now if today.IsDaylightSavingsTime and not d.IsDaylightSavingsTime then d = d + new DateInterval(0,0,0,1,0,0) ElseIf not today.IsDaylightSavingsTime and d.IsDaylightSavingsTime d = d - new DateInterval(0,0,0,1,0,0) end if

DateTime is trying to adjust the hour from/to Standard Time and Daylight Saving Time. In this example you get -1 hour, the other way around you get +1 hour.

except the intervals arent always 1 hr :slight_smile:
heres one we all know & love in canada
https://en.wikipedia.org/wiki/Newfoundland_Time_Zone

[quote=484090:@Norman Palardy]Constructing a date doesnt give you the GMT offset that was in effect on that day & time
It gives you TODAYS gmt offset
Seems the new DateTime does that as well - which is horribly wrong
That should be reported as a bug if it hasnt been already[/quote]
This doesn’t happen with DateTime. DateTime correctly creates a DateTime with -18000 seconds (central time) for today, and -21600 for 2020-01-01

I think the problem is that they want to take into account the 1 hour difference when the system only expect something like:

202001010000.00

good (i didnt try it as I’m in the middle of debugging some other code)
that would be horrible if it didnt as that was always an issue with the old date class

DateTime seems to be doing the correct thing, but it seems to be going wrong when assigning the Creation and Modification DateTime properties of FolderItems.

Here’s a better workaround, for folks in New Foundland, etc :-):

dim today as DateTime = DateTime.Now if today.IsDaylightSavingsTime <> d.IsDaylightSavingsTime then dim diff_secs as integer = today.Timezone.SecondsFromGMT - d.Timezone.SecondsFromGMT d = d + new DateInterval(0,0,0,0,0,diff_secs) end if

[quote=484094:@Norman Palardy]except the intervals arent always 1 hr :slight_smile:
heres one we all know & love in canada
https://en.wikipedia.org/wiki/Newfoundland_Time_Zone[/quote]
I think the issue here is DateTime trying to give a time considering DST when it shouldn’t. So I don’t think this matters here because the DST is 1 hour too.

Anyway, is a bug or error in design that should be fixed.

Edit: Created feedback://showreport?report_id=59781 I hope is clear

Well did some tests and it looks like the bug, even if DST related, should not show itself if using a Time Zone that doesn’t use DST like:

Dim d As New DateTime(2020,1,1,0,0,0,0, New TimeZone(0))

I was expecting a different date-time but still got Dec 31 23:00, maybe a different reason.

It get’s even weirder. When you read back the modification and creation dates from the file (see code below), it returns the correct date, even though the dates of the file on the disk are off by 1 hour.

[code]dim f As new FolderItem(“Test File.txt”)
if f <> nil then
dim t as TextOutputStream
t = TextOutputStream.Create(f)
t.Write “This is a test”
t.Close
end if

dim d as new DateTime(2020,1,1,0,0,0)

f.CreationDateTime = d
f.ModificationDateTime = d
f = nil

f = new FolderItem(“Test File.txt”)
MessageBox f.CreationDateTime.SQLDateTime + EndOfLine + f.ModificationDateTime.SQLDateTime[/code]

I submitted a bug report: feedback://showreport?report_id=59790

[quote=484265:@Roger Meier]It get’s even weirder. When you read back the modification and creation dates from the file (see code below), it returns the correct date, even though the dates of the file on the disk are off by 1 hour.
[/quote]

I don’t think that is weird, I see it as consistent. If 1 hour off is set for the date, then when read 1 hour off, will show the correct date.

BTW feedback://showreport?report_id=59781 and feedback://showreport?report_id=59660 marked as Fixed, thanks @William Yu