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)
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).
[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
[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.
[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:
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
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.
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]
[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.
