If your data is in local time, the data will be much less useful then being in a universal format. Or you end up building a service for other people to consume your data. Maybe today you’re using the data in one location but maybe in the future you have a Web application and you have multiple locations that access the data.
The simple reason is: Things change! You never know how the data that you are capturing today will be used in the future. I often get questions about why you should – and you REALLY, REALLY should - store dates in UTC format. Typically this date format is UTC time – or zero offset time. UTC DatesĪ generally accepted solution to this problem is to store date values using a single time format that is adjusted from local time.
You can see where this is going – dealing with dates from multiple locations around the world can get complicated fast. Some countries have it, others don’t, and surprisingly – some countries actually half hour DST offsets. Usually it’s “spring forward” and “fall back” with time getting set one hour forward for the summer. Most of the world – especially those further away from the equator – have daylight savings time which is applied on different dates in different locations around the world. The problem of local times is made worse by Daylight Savings time. If you build applications that deal with customers that enter data into a system from multiple locations then using local times becomes problematic. As you know if you’ve ever talked to somebody half way across the world at a certain time of day, while you just got done with breakfast, they are getting ready to go to bed on the other side of the world. Here’s why and how we can address these issues… TimeZones and Offsetsĭepending on where you are in the world your local time is defined by an offset from UTC ( Coordinated Universal Time) time or the baseline zero time. For FoxPro in particular it’s not natural to store dates in anything but local machine format as the language doesn’t support direct UTC formats so it’s very common to see FoxPro applications use local dates which is usually a bad idea. The sneaky thing with date time management in larger applications and especially applications that live on the Web or are shared across locations, is that problems don’t usually show up until much later in the lifetime of the application.
Representing dates and times across timezones can be a challenge especially if you don’t lay out a plan up front on how to store dates consistently.
0 kommentar(er)
