First time on SO and I have a question that I'd like to get your guys' opinion on:
I work on isolated machines (linux OS, no network connections) and one of the issues I'm running across is what should happen when the user Enables an auto DST setting that I've made.
Since not all areas observe DST, the settings requires an 'on/off' type of setting. Furthermore, since the start and stop days seem to vary with the whims of politicians, it can be configured with start month/day/(1st,2nd,3rd,4th) along with stop month/day/(1st,2nd,3rd,4th). Yes, I left out '5th' but I don't envision that ever being a start/stop condition. So now the start and stop periods can be defined as flexibly as '1st sunday of march'.
Now the meat of the question: What then should happen when DST is enabled/disabled? I think I would expect it to auto-change the current time if the date & month falls within the DST period. At the same time I have a few users saying that it's a bit strange when the following workflow happens: Set time to 11:00 AM, Set date, Enable DST, time jumps to 12:00PM. Would it make more sense to not change the time upon enable/disable and just wait until the next DST date to correct it?
Looking forward to hearing some opinions :) TIA
I don't know that there's a best choice here. I think it comes down to user preference. Personally I'd probably apply the adjustment when the option is changed, but also try to make the resulting (possible) jump in the time obvious to the user so that if it's not what they expected, they'll know right away that they need to adjust the clock.
Depending on which locales you may need to work with, you should also be aware that not everywhere uses the "first Sunday in March" style for determining when to switch to/from DST. Some places use arbitrary dates hand-picked each year, others may use a specific day of the month. The time of day that the change occurs at varies as well, and some places base their changeover time & date on UTC while others base it on local time. You may need to account for several variations on how the changeover dates are determined unless you're only dealing with a limited set of locations that are more consistent in how they do this.
Even just in Canada, there are places that change at midnight and places that change at 2:00AM, and some that don't change at all.
Related
Wow! Tons of posts on converting GMT to local time, including correction for DST. But it seems my need is different.
As the title says, I have a stand-alone embedded system with no O/S. I'm using NTP to get UTC. That is used to tag events with an accurate date/time. I can correct UTC for the current time zone but cannot automatically adjust for DST.
Since there is no O/S, I don't have any of the Windows/Linux data such as time zone. So there is no way to locally adjust for the GMT offset.
It seems the only way for me to do this is to use an http call to find the offset, and the only way I can think of doing this is using the lon/lat or address. It would be possible for me to add lon/lat or address to the configuration so this seems like the only option.
I've seen references to sites which return the GMT offset based on location. Do these sites also automatically adjust for DST? To do that, they would have to use one of the solutions posted in many places in this forum, but that should be easy enough.
Thanks for the advice and help!
Dave
If you need to only convert a specific single timestamp to local time, then yes - you can use services such as those listed here. At least the ones offered by Microsoft and Google do convert a timestamp to the local time in the time zone given, in addition to providing the IANA time zone id.
Additionally, you'll find that the gettimezonebycoordinates function in the Microsoft Azure LBS Time Zone API returns a PosixTz value, such as "PST+8PDT,M3.2.0,M11.1.0". This is ideal for embedded systems, as you can set your TZ environment variable to this value and then many local APIs (such as with C, and others) will use this value in their conversions. This approach works best when you may be converting many different local time values and don't want to make an http call for each one.
Be aware, however, that using a POSIX time zone string has some limitations, such as being restricted to a single set of DST transition rules. They generally work ok for near-current time ranges, but not for historical purposes.
How well known is this one. ALL the modified dates on hundreds of word documents are different to day than they were on Friday. They have all changed by an hour.
Is this a bug or a feature.
My analysis: The clocks changed by an hour over the weekend, so helpfully, Microsoft has reset ALL of the modified dates across the entire system. Presumably in six months they will all change again.
A routine I run daily, that normally takes six minutes to pick up any changes or new documents, is today taking HOURS, and recording hundreds of non existent changes.
This is an operating system issue; not a Word issue. And yes, it reflects the change in local time between standard and daylight savings/summer time. Any time-stamp dependent routine should take account of that.
I've been tasked with handling import jobs in to SQL server based on various time zones. Files arrive on a Windows Server from multiple regions for example Brazil, Singapore, Australia, various parts of the U.S. and also Europe.
Each file will be imported in to SQL tables by multiple stored procedures. Each stored procedure needs to be executed based on a scheduled time according to the time zone related to the origin of the file.
Working from a set time is proving tricky due to the fact that each region adjusts for day light saving at different times of the year. Say for example the UK moves it's clock forward for day light saving, Brazil may not move their time forward for another 3 weeks (don't quote me on that, I've used those times only for example purposes).
My question is; how can I schedule jobs to run on the same server based on multiple time zones?
I can see this may be possible if I were to create a timezone lookup table in SQL which shows the relationship between each time zone at each stage of the year but this seems quite cumbersome and will also take a considerable amount of time to populate the table.
Windows scheduler seems to use the date/time settings of the local server and although it does adjust for daylight saving, this will only be appropriate for one region. Has anyone had to handle this in SQL Server before? Or can anyone recommend a scheduling tool external to SQL Server that can initiate tasks based on different time zones?
Any help or advice would be greatly appreciated.
You won't be able to transparently and easy configure a single instance of SQL Server to run several sets of tasks in different timezones, by definition (the instance is single, all sets of tasks will be in the same timezone).
You are, however, able to write your own script in any language you like (for example, CLR .NET extension for MSSQL or just plain Transact-SQL), which is configured to to the following:
Iterate over the list of each region you want the task to be run
Convert the time of the region to server time and set the action to be executed (via sp_schedule for example).
Repeat the next period.
This task should of course be run at +12 UTC, thus definitely making it execute first on that date (as the time conveniently starts in Japan).
Implementing it this way would be pretty clear and reliable regardless of daylight savings, timezone updates and everything. Just make sure to keep the configuration of your partners timezones up to date.
I want to add a feature to my trial version of the application. After first activation, I want to make it limited to 90 days. But I am concerned about user's changing the date of system hence deceiving my application.
Is there any possibility to make it fool proof in a way that even if user takes the calender back, application expires after 90 days of first activation? First activation date has been saved in the database.
Thank you very much.
Furqan
In short, no, unless your application can run 24/7 and only allows itself to be started once. Even then, there'd be ways to subvert it.
#SB.101's answer is a way of checking for very simple date fiddling. It won't catch sophisticated cheats who know you're doing that and just keep setting the date to something sneaky that fools your checks. It will also annoy the odd few users who change the date on their system legitimately.
Pinging a server of yours over the internet to get the date would help, but is still able to be spoofed, and now annoys your users by forcing them to be connected to the internet (unless your application already needs that).
There is no sure-fire way of doing this. It is theoretically impossible. Remember that no matter how clever you are at checking whether the trial period has elapsed, a user can always modify or delete the recording of when the trial started!
I would advise you to just do something quick and simple, and rely on the fact that the small percentage of people who are both able to subvert your trial limitation and willing to bother doing so are unlikely to purchase the full version of your application anyway.
You can also save last run date in DB and can compare that to system date if that is newer that system date then you are deceived!
or
If you can use HTTP then can query time servers for current date time
I'm writing some software to track if a file has been checked out and changed. The file could be checked out and changed by various people in several different time zones.
So, simply put I would be doing something like this:
if ( checked_out_file.last_modified_date > my_database_record_of_the_last_modified_date ) {
// file has changed since last sync so do something
}
The above is just pseudo-code so don't get hung up on what language and things like that. What I am basically wondering is should I store the my_database_record_of_the_last_modified_date as the UTC time, and when I do my checked_out_file.last_modified_date comparison, as illustrated in my pseudo-code above, should I also use the UTC time for that?
Time is a pain to work with. Time zones are even worse. There's not much you can do about that. But if you use UTC everywhere, you can make time a little more bearable.
Store all your dates in UTC. Do all your date comparisons in UTC. Do everything you possibly can in UTC. Ideally, the only time a date won't be in UTC is when it's being formatted for display to a user. Time zones are a rabbit hole you do not want to go down.
Hope this helps!
PS: Yes, I've had bad experiences with time zones in the past. Could you tell?