folderItem.creationDate can't set timezone

General
#1

I’m trying to set the timezone on a folderitem.creationDateTime but when I do it resets to timezone to the current timezone.

Example:

[code]//apply the time zone & date from text field
Dim secs As Integer = Val(tf_createdTZ.Text)*3600
Dim tz As New timezone(secs)
localDT = New datetime(nsdp.DateTime.SecondsFrom1970, tz)

//localDT shows the correct timezone
tf_localDate.Text = localDT.SQLDateTime
tf_localTZ.Text = Str(localDT.Timezone.SecondsFromGMT/3600)

//file shows the local timezone
file.CreationDateTime = localDT[/code]

Bug or feature?

Is there a work-around?

40 minutes difference between Xojo and Finder time files
#2

the machine is always using the timezone its in so files should always be set to the current time zone

what is it you’re trying to achieve by setting a creation date time in a different time zone ?

#3

Photos and Videos taken in a different timezone e.g. GMT on the camera’s settings, are showing up in the wrong timezone. Would like to be able to change them to the timezone in which they were taken.

Example - camera set to GMT, take photo, creation date shows midday GMT. Open on mac, shows midday local TZ. Wrong answer.

Nothing in manual on Folderitem says it will strip TZ and reset it to the local timezone.

#4

you’ll probably have to convert the date time to the local tz

#5

OK, I think…

So when I open a file, does the creationDate.totalSecondsFrom1970 represent the seconds from GMT or from localTime or from the timezone when the file was created?

#6

The the MacOS layer (way down deep) a file date is an NSDate
NSDates are immutable points in time

So a “file creation date” can be displayed as just about anything reatvie to some calendar tz etc but it really is not tied to any of those

How Xojo interprets that data to pass it back to you I dont know
As long as its using NSDate “somewhere” in that pipeline of data from the file system to you and back again I would expect that it would get set right but that seems to NOT be the case from what youre saying

That would seem to be a bug
As if its getting set from a Date without consideration of the timezone at all

#7

Based on Apple’s NSDate (for which thank you) then the seconds count is relative to GMT and does not change as the TZ changes - which implies the timezone is just a convenience method to show the time in that timezone - which seems logical.

However there does seem to be other screwy stuff going on. Doing some simple tests using a single file, and changing the timezone in System Preferences I get the following strange results for createdDateTime (UK format dates d/m/y)

                                     Jamaica-5                                  BST 0                             Mumbai+5.5

Finder 1/3/2009 08:45 1/3/2009 13:45 1/3/2009 19:15 << expected results
DateTime.sql 1/3/2009 08:38 1/3/2009 14:45 1/3/2009 19:06
nsDatePickerMBS 1/3/2009 03:38 1/3/2009 14:45 1/3/2009 00:36

The dateTime in Finder changes as expected as the timezone is changed in preferences.

For BST the differences between Finder and the other 2 might be due to Daylight Savings time in the UK - maybe.

Cannot explain the difference of 7 minutes and 4 hours 53mins for GMT-5 and various minutes for GMT+5.5.

#8

[quote=492519:@James Pitchford]I’m trying to set the timezone on a folderitem.creationDateTime but when I do it resets to timezone to the current timezone.
Bug or feature?[/quote]

[quote=492541:@Norman Palardy]That would seem to be a bug
As if its getting set from a Date without consideration of the timezone at all[/quote]
Just fyi: <https://xojo.com/issue/59781> FolderItem Creation/Modification Date difference with API 2.0 (DateTime)
But honestly, I haven’t studied this Thread in detail. Well possible you’ve discovered something else that’s not covered in the linked Feedback Case.

#9

Further investigation shows that the old Date class shows the same thing - more or less - though it does get a different result for the number of hours London is from GMT.

So 2 bugs to file:

  1. setting folderitem.creation/modification date/dateTime(s) doesn’t take account of the timezone information, just assumes it is local TZ.
  2. calculation of dateTime and date properties in non-GMT timezones give different results than those shown in Finder.

Seems related to https://xojo.com/issue/59781 which says closed - but seems it is not.

#10

Keep in mind that the file’s creation date may or may not match the date & time information stored in the EXIF metadata.

In this example, you say “creation date shows midday GMT”. Where is that data shown?

#11

This was my misunderstanding of how timezone works - and on further digging I am probably more confused.

What I believe should be happening is:
The secondsSince1970 should be a number representing the delta in seconds between 00:00:00 UTC on 1 January 2001 or some other specified date (presumably 1 January 1970, 00:00 GMT in Xojo’s case). Thus regardless of where date was created, or the date is read, this number should be constant/immutable/invariant (depending on your preferred nomenclature).

Based on that number, a little division, some poems about leap years and days of the month, and application of the timezone delta and the daylightSavings delta you end up with a presentation of local time in all the day, month, sql etc properties.

You can see the impact of the latter by changing the timezone in System Preferences and see the resultant created dates in Finder get changed to the equivalent local time.

If the above holds true then it is relatively easy to convert the dateTime into any timezone required. All good so far.

But, not all cameras do this - most will simply allow setting of a datetime without knowledge of the timezone, some will include the timezone (within EXIF data), some might use GPS data. So my app (which is trying to file photos in a consistent date structure) will need to have knowledge (manually or automatically) of the timezone in which the file was created - and then adjusting the to the desired timezone for the archive. Lumix, for example, allows setting of a home timezone and a destination timezone, setting the camera’s time to whichever is wanted. The challenge here is that the createdDate timestamp seems to be the camera’s time, rather than by reference to UTC or GMT, though the EXIF date does include the associated timezone data.

So, I would have expected that in specifying a timezone for a new DateTime, that this timezone would be used to calculate the constant/immudable/invariant secondsSince1970, and further, that this value be used when applying the date to the files createdDate - but it seems it is not.

But, double but, when I check the secondsSince1970 value, I see that this constant/immutable/invariant value is also changing when I adjust the System Preferences timezone. Which knocks all my above theorising on the head…

If I had some more Swift knowledge I would probably test it there to see if it does the same thing as Xojo.

#12

Having done some work with DateTime recently, SecondsFrom1970 should always be the same, no matter what the TimeZone is set to. TimeZone is purely used for determining how to display a date/time (including daylight savings adjustments).

Keep in mind that the older Date object wasn’t built this way. For best results, make sure you’re not mixing Date.TotalSeconds wIth DateTime.SecondsFrom1970.

If you’re still having problems, post some sample code or a sample project for us to look at.

#13

I have a short app - here.

It does what you describe using a fixed date instance - e.g. dateTime.now.
But when checking a folderitem.createdDate, the secondsSince1970 moves as the timezone moves - not expected.

  1. Choose a file, 2 Press start monitoring, 3 change the timezone in System preferences, 4 watch the seconds move.
#14

if you always show them as UTC though does secondsSince1970 change ?
thats what its relative to and so if you change timezones to look at it the seconds might be reflecting the same value but in a different tz
thats what I expect is happening

you’re seeing the same value represented in the local tz

#15

If show them as UTC - then that’s not changing the timezone…?

But that is different to what Greg is saying and what I would expect.

#16

not really no

If we pick a time - 0 seconds from 1970 UTC and we are IN UTC then that time is “seconds from 1970 = 0”( right ?)
but what time is in Eastern Std time ? its UTC - however many seconds (right ?)

but its the same point in time represented 2 different ways relative to 2 different timezones

I expect what you’re seeing is that effect where “seconds from 1970” in Xojo considers the timezone and thats what you see going on

But at the very lowest level in the OS its relative to UTC

#17

I’m not understanding Norman. UTC is UTC wherever you are in the world. SecondsFrom1970 is relative to UTC and should also be constant. To get your local time you add GMTOffset to SecondsFrom1970(UTC).

Your Xojo manual specifies [quote]The number of seconds since the first 1 January 1970, 00:00 GMT.[/quote] and not the number of seconds since first 1 January 1970 local time - so is consistent with the OS.

#18

To take the argument a step further - how do you cacluate an interval between 2 dateTime instances in different timezones? If the secsFrom1970 are relative to GMT (or UTC) then is is simply the delta between the two values. If it is as you say then you would have to add in GMTOffsets for both, and Daylight saving time for both - which I doubt you do.

#19

[quote=492770:@James Pitchford]I’m not understanding Norman. UTC is UTC wherever you are in the world. SecondsFrom1970 is relative to UTC and should also be constant. To get your local time you add GMTOffset to SecondsFrom1970(UTC).

Your Xojo manual specifies and not the number of seconds since first 1 January 1970 local time - so is consistent with the OS.[/quote]
Yes. … as long as you view the time AS UTC it will remain constant
But you’re not - you’re changing the local timezone and seeing that “this time in UTC is this other time when expressed in the local time zone”

I would bet that Xojo’s seconds from1970 is also considering the timezone as well and is not the low level NSDate where that is 100% always expressed as UTC

I see the docs DO say it it relative to GMT but the effect youre seeing when you change the timezone makes no sense then
as if it IS considering the timezone
this is all wrong …

#20

I have
in fact I have code to do that in the old API 1.0 code base for historcal dates as well to know IF daylight was in effect