Date Picker that uses Xojo.Core for Dates?

Hi guys,

Does anyone know if there’s a DatePicker Control (Addon/Plugin) out there that uses Xojo.Core for dates?

Thanks in Advance.

No, but why would you want that?

Ok, so my understanding is that the Date class in Xojo.Core is the ‘new’ way to deal with dates?
I’m using a date picker that complains when I try to assign a xojo.core.date to it instead of just ‘date’. This means I have to convert my new date to the classic(?) date class.

I just want a control that understands the new date class.

Does the one you use have the source code available?

I don’t think so, it’s just a plugin in the Xojo plugins folder.

DateControl.xojo_plugin

ahh… So it’s a third party plugin… Ask the developer to update it for the new Date class…

Using new framework in plugins is a lot of extra work.
Maybe better ask for efficient auto conversion for new to/from old types.

Here is what I use.

Date Picker (With XojoCoreDate).xojo_binary_project

I added XojoCoreDate methods.

You can set the date like this:

dim d as new date
DatePicker1.DateValue = d

'or use new date type
Dim d1As Xojo.Core.Date = Xojo.Core.Date.Now
DatePicker1.XojoCoreDate = d1

And get the date like this:

dim d as new date = DatePicker1.DateValue

'or use new date type
Dim d1 As Xojo.Core.Date = DatePicker.XojoCoreDate

[quote=340677:@Neil Burkholder]Here is what I use.

Date Picker (With XojoCoreDate).xojo_binary_project

I added XojoCoreDate methods.

You can set the date like this:

dim d as new date
DatePicker1.DateValue = d

'or use new date type
Dim d1As Xojo.Core.Date = Xojo.Core.Date.Now
DatePicker1.XojoCoreDate = d1

And get the date like this:

dim d as new date = DatePicker1.DateValue 'or use new date type Dim d1 As Xojo.Core.Date = DatePicker.XojoCoreDate [/quote]
Your code doesn’t take time zones into account. When converting remember to do this:

dim fromDate as new date Dim epoch as new date(1970,1,1,0,0,0,fromDate.gmtoffset) Dim tz as new Xojo.Core.Timezone(fromDate.gmtoffset *3600) Dim diff as double = fromDate.totalseconds - epoch.totalSeconds Dim toDate as new Xojo.Core.Date(diff,tz)

Wow thats a lot of work just to convert a date? (I never used the new Xojo.Core.Date before)

Couldn’t Xojo have added conversion convenience methods to Xojo.Core.Date? I guess an extension method could be written.

Something like this:

[code]dim d as new date

d = MyXojoCoreDate.LegacyDate
MyXojoCoreDate.LegacyDate = d
[/code]

You could always take the above code and make an global method that will do it for you…

The code from Greg shows the new framework in all it’s awful glory. When do I care about timezones? Very seldom.

On the contrary, I believe you need to care about timezones all the time. That was Greg’s point.

At least assuming you do not want the date/time values to shift on you.

What are timezones? :wink:

But you should care about timezones. That’s the whole point. The simplicity of the old date class comes with the problem of making it look like it does things right across time and timezones when it really doesn’t. The reason I included all of that timezone stuff was that I didn’t know what the timezone of the original date was. If it had been Zimbabwe, the TZ offset would have been very significant to the user.

Ever try to get the # of seconds between two dates when one is before daylight savings time and one is after? The timezone where you do that calculation matters.

Did you know that Timezones change from time to time? Or that parts of Indiana and Arizona don’t observe daylight savings time at all? What does your app do if a user moves in or out of those areas (lives in New Mexico and works in Arizona). Does it handle that properly?

And did you know that in 2006, Indiana changed so that all counties now observe DST? Whereas up through 2005 the counties in the Eastern TZ did not observe it, making the entire state have the same time those in the Central TZ.

I understand the issue on a phone… But I hope my desktop don’t move very far!

BTW the date picker i posted was only tested on windows. I just added the new Xojo.Core.Date feature so it’s not really tested.

But if it is in a locale that observes some variation of DST or Summer Time, Greg’s sample code accounts for the difference in the GMT offset of the from time and the GMT offset of the to time. Which means calculating elapsed time is accurate, even when your desktop does not move. The (effective) timezone still can change. And does in much of the world. Just not all on the same dates.

While your immediate need is to do something for your desktop, imagine something like an ERP system: the order is taken by someone on the phone in in the Eastern US. The system is located in Western US. Scheduling is done centrally by the server and the shipping occurs in Japan. What goods issue date and time do you tell the shipping staff in japan? You want to confirm shipping and delivery dates and times to your client in Germany. What dates and time will you confirm to the client? - The best practice is to use his locale and timezone. This is made easier with the new date class. Local dates and times will not work, and you cannot expect everyone to use pacific time. Everyone will be accessing the information more or less real time, and the time and date display needs to make sense to users in every location.

My example may be a bit extreme, but it illustrates the challenge of working with dates and times when multiple entities share or interact with the data in different locations. This is the kind of scenario where I see the new date being most useful.

I did not… so that’s one thing that Xojo.Core.Date should get right though… handling dates correctly before and after 2006. :slight_smile: