I’m working on a project that relies heavily on date manipulation. Before I started, I read a ton of stuff on the internet to familiarize myself with Xojo’s date processing abilities. Most of what I read was from people that didn’t like the newer Xojo.Core.Date object and most were pretty vocal in their praise of the old Date object.
But I really need the TimeZone awareness of the Xojo.Core.Date object. After messing with the Xojo.Core.Date object I have to say, I don’t think I’ll ever use the old Date object again. Once I got the lay-of-the-land I began to see that there are only three main objects in the Xojo.Core date library (Date, TimeZone and Interval). These three objects work together to do all the heavy-lifting. I found it pretty easy to use these objects together to create a web calendar dialog that could handle leap-year issues without me having to provide additional logic. Everything needed was in the new date library. I just had to get comfortable with the Date/TimeZone/Interval trinity.
At first I wasn’t sure how I felt about the new Xojo.Core.Date being immutable. But again, once I started putting the date object to work it started to make sense that a date object should be unchangeable. If you need to derive a new date, just create another date object. Pretty soon I was finding it easy to create, use and discard date objects as needed.
The only issue I had that made learning the new date library somewhat difficult was the lack of auto-complete when employing the “Using Xojo.Core.Date” clause. During the learning phase I simply used the fully qualified library names: Xojo.Core.Date, Xojo.Core.TimeZone and Xojo.Core.Interval and the auto-complete worked just fine. After I was finished coding, I added the module level “Using Xojo.Core” clauses and did a search and replace to get rid of the Xojo.Core references scattered around my code. Now my code is working and tidy.
Given that I’ve been a Xojo user for a little less than 2 years I didn’t really have any attachment to the old date library although I did use it for some basic stuff. But when I needed the extra power of the new date library it wasn’t terribly difficult to make the switch. So, if you haven’t warmed up to the new Xojo.Core date library, I’d suggest giving it another look. It’s worth it.
Here’s a screenshot of the date/time picker I built using Xojo.Core.Date for a Xojo web project I’m working on. It is timezone aware and always returns UNIX timestamp. It makes selecting an exact point in time easy:
AFAIK for Cristians He rests the seventh day and that’s the sunday, therefor the week starts on monday. Beyond that the ISO-week also starts with monday.
So no, my calendar doesn’t allow the start of week to be Monday.
However, the way you choose to define the start of the week is merely a presentation issue. Given that the Xojo.Core.Date is based on UNIX time internally it becomes obvious that everything about a date/time picker is a presentation issue since a raw UNIX timestamp is meaningless to humans without adding a presentation layer on top of it.
So, there’s no reason why the date/time picker couldn’t display Monday as the start of the week if that is how you choose to present it. I chose to adhere to the accepted presentation for my culture.
[quote]System Prefs -> Date & Time -> Date & Time Tab -> Open Language & Region
[/quote]
And there it is: a pulldown which allows the user to specify any day as first day of the week.
And there it is: a pulldown which allows the user to specify any day as first day of the week.[/quote]
That’s pretty neat. But I don’t think that that option is available at the OS level in Windows or Linux. And getting something like that to work for a Xojo Web app which runs on a server (not on your local machine) would render an OS based first day of week option useless. Since this is a Web based date/time picker, I would have to let the user designate their choice of the first day of week.
