Is thee some way of implementing a custom time zone in windows?
We have some PCs in Creston, British Columbia, Canada (Time zone exception) which stays the same time all year. So essentially, Creston does not observe a time zone. Can I implement this behavior in windowsÉ
I wrote a lengthy blog post about a similar problem we had: http://subjectivecoder.blogspot.com.au/2013/04/creating-custom-windows-timezones.html
The short version is that there is a spot in the registry which allows you to modify or create new time zones - but the registry format is fairly nasty.
Microsoft has a GUI tool called TZEdit which you can find here: http://support.microsoft.com/kb/914387 (scroll down to Method 2 and download TZEdit.exe).
If you want to see what's going on behind the scenes, I've published the source to the command line tool I built here: https://github.com/Rophuine/TimeZoneInfoGenerator (it's untested and quick-and-dirty but may help you understand what's going on, if you're interested).
Apart from daylight savings time, this is normal MST (UTC-0700), right?
Windows used to have a checkbox called something like "Automatically adjust the clock for daylight savings time". Maybe you can hunt that down. Even if there is no checkbox, chances are that the registry setting still exists.
The data is in: HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Time zones.
You can probably add your own zone.
Each zone has its own key. And they contain a lot of data. Some zones have a subkey Dynamic DST.
This is not exactly an answer, but you might consider trying to get Creston recognized as an official time zone. As for how exactly to do that... contact Microsoft, I guess, and ask where they get their time zone info from. Probably the closest thing to an official time zone database in computer programming is zoneinfo but I'm not sure if Microsoft uses it.
WARNING: You should be very careful about creating your own time zone, even if you think your systems are isolated.
This could cause problems with exchanging information with other systems, both from conversion errors as well as exception handling.
If the time zone you want is legally recognized, you should consider bothering your vendor to properly add you to the time zone repository they use.
Related
I need to store datetime records with IANA database current version used (2022g for example). How could I get it with Go?
I tried to search this on standard "time" package, but it seems that there isn't any functionality for this. I am expecting that there is some function that can return IANA tzdb version as a string.
UPDATE 1 according to comments below I need to clarify the problem:
The main problem is I want to store some FUTURE events. The event object has several fields:
Local dateTime
Timezone
UTC datetime
To keep my data up to date with IANA database (timezone, daylight saving time may change) I need to store current version of tzdb version. That will help me to write correct data migration of my events when new version of tzdb was released. So I need to add one more field with version of current tzdb that had been used to populate the time.
And I am trying to figure out how can I get the current version of my tzdb that Go application is using right now to store that version.
Also I am opened to alternative solutions of storing time records with extra accuracy of long-lived future events.
Update 2: This events are bounded to exact location.
The discussion thread in the comment is pretty long, but I'll attempt to answer and address some of the concerns. (I won't address the question in the title, as I believe that is not straightforward in Go.)
Indeed, future scheduling of events should be in terms of the time zone where the event takes place - which is usually not UTC.
Time zone identifiers will never be removed or renamed (with rare exception anyway). Once introduced, the identifier will either maintained as a Zone or as a Link in the TZDB indefinitely. Thus, you don't need to check that the time zone still exists. (Windows time zone IDs are also like this.)
DST is only one aspect of picking the correct offset. The standard time may have changed as well. However, all of that is encapsulated in the tzdb itself. You shouldn't need to concern yourself about which version of the tzdb was in effect when you created the event.
The general approach to this issue in most cases is:
Store the scheduled local date, time, and time zone ID of the event (local with regard to the time zone of the event).
Example: 2030-12-31T00:00:00[America/New_York]
At the time you create the event, also calculate a UTC value (or equivalent DateTimeOffset value) and store that in a separate field - so you know exactly when to fire the event:
Example: 2030-12-31T05:00:00Z (or 2030-12-31T00:00:00-05:00)
Periodically check that your UTC equivalent is correct. This can be in a daily maintenance task, or on application startup, or just before the event (perhaps also an hour before the event), or all of these.
The offset will only be different than projected if the time zone data changed on the device to give it a new offset. For example, let's hypothetically say the lawmakers in the USA succeed at making DST permanent sometime before this event takes place. Then the equivalent UTC time for the same event would now be 2030-12-31T04:00:00Z (or 2030-12-31T00:00:00-04:00).
In such cases, update the UTC time of the event if it has changed, but the original local time of the event usually should not be modified. Human beings tend to schedule things in terms of local time, not in terms of their UTC equivalents.
The only advantage knowing the TZDB version would give you, is you could do that last step less often - only when knowing the data has changed. I see that as an optimization though - it's not usually required.
Without such legal changes to time zone definitions, the mere start/stop of DST as scheduled is not a reason to worry about this. That is already accounted for by using the TZDB in the first place.
If the event is recurring (say a 10:00 AM daily meeting), each occurrence might have a different offset, but the local time will be consistent and the TZDB doesn't need to be updated to calculate it.
Perhaps this question should be broken up into two posts, but I currently have an API for a few business customers. I am currently using ISO 8601 timestamps with a UTC time zone to represent times. However, I don't like the idea of these timestamps being attached to any timezone because the times should be the same no matter what timezone you are in. 5PM UTC should be 5PM CST, etc...
I know that you can leave the Z off of an ISO timestamp, and it will be interpreted as whatever local time you are in. Is this ok practice? And if so, how do I do this in Ruby? I read the doc for the Time class and didn't see anything about this.
EDIT: Let me re-word this just a little bit, or atleast clarify something. The reason why I'm seeking timestamps that aren't attached to a timezone is exactly because I know that my client servers and API server will hardly ever match up. If a client is submitting an event with a time, that time needs to be ambiguously equal to the ambiguous locale specific to the event that the user is working on.
That's a mouthful...assume that I'm working on an event scheduler. Each event belongs to a storefront or location of a company. When times are being shown for a location, it is assumed that the times shown are in the timezone of the location, and for clarity's sake should never be shown at a time formatted to a user's local timezone. If I'm looking at the scheduler on the East Coast, but looking at events for locations on the West Coast, the times I should see should be local to the locations on the West Coast, not adjusted for my timezone.
I know a solution could be to simply store times with timezone information for the location its associated to. But the use case that a user would want to convert a time to their timezone is VERY rare, and I'd rather make implementing my API easier...this was actually my original implementation but implementing the API in many different environments and across multiple programming languages, it became clear that it is a hurdle to show times local to that timestamp's timezone for a lot of languages. If a user wanted to convert times to their local timezone I could easily store global timezone information for the location object itself.
I don't know what you mean by "the times should be the same no matter what timezone you are in. 5PM UTC should be 5PM CST, etc..". 5PM UTC clearly isn't 5PM CST!
Anyway, I don't think that what you are proposing is an ok practice. Suppose you leave off the Z and have a timestamp be interpreted as whatever local time you are in. Since this is a network API, the client and server might not be in the same timezone. When the client submits a "local" time, what does it mean? The local time on the client (if so, how does the server know what that is?)? The local time on the server? It's ambiguous. This is the crux of the reason why just about the only reasonable thing to do is to use UTC throughout.
What you can do is attach a timezone to a timestamp if it might be relevant. For example, "you should observe one minute of silence at 2012-11-10T22:00:00Z in honour of the soldiers who died in WW1" sounds weird because Rememberance Day isn't on November 10! "you should observe one minute of silence at 2012-11-11T11:00:00+13:00" sounds a lot better once you put that New Zealand time zone in there... In this case you can keep and timestamp (in either local or UTC) together with the timezone offset (e.g. store both of them together in your database).
It does, however, depend on what your times represent. For example, in "at equinoxes, sunset happens at 18:00" it makes sense to use an abstract time that isn't qualified with a timezone (it's true in every timezone, and/or you're talking about solar time). But attaching a date to this abstract time makes little sense, so I don't think you would be talking about ISO8601 in this case.
I want to have one feature in my windows phone application where i will require to see if for the time zone whether the daylight settings is currently on or off.
I can get this detail for the time zone which is set in my phone, but what i want is that i can get this for any time zone i pass or set.
For example, if i pass time zone "Antarctica/Palmer", i should able to find whether currently daylight setting is on or off. I tried few things but not able to find anything. I do
not want to use any web api to give me this.
Is there any facility where i can set the timezone via code to get the result and then revert it back to original or some other solution?
Thanks.
There's the IsDaylightSavingTime method:
Indicates whether a specified date and time falls in the range of daylight saving time for the time zone of the current TimeZoneInfo object.
It requires you to have a TimeZoneInfo object, but you indicate that you already have that.
For example, if i pass time zone "Antarctica/Palmer", i should able to find whether currently daylight setting is on or off.
That looks like a zoneinfo/tzdb/Olsen time zone ID to me, not one that Windows in general uses. My Noda Time project uses tzdb and would be able to get you that information, but we don't currently build a Silverlight version - we probably could with a bit of work, but it wouldn't be trivial. Patches would be welcome, of course...
Do you definitely want to use tzdb IDs, or would the appropriate Windows ID be okay for you? Unfortunately TimeZoneInfo.FindSystemTimeZoneById appears not to be supported on Silverlight :(
In the iphone game "Tiny Tower", I'm guessing it uses some kind of simulation based on the time spent between the last play and the current time, because you can set the current time forward and you will get the benefit from the fake elapsed time span.
Is there an algorithm that I can use to prevent this sort of thing? (Or at least make it difficult enough for the average user to pull off!)
Edit: thanks, I understand that, despite my wording, there's no way to prevent things you store on the client side, but I want to make it at least more difficult than "changing the time" to hack it!
The gamecube had a way to do this so it must be possible.
Is there an event triggered when the iphone time is set ? In that case you can react that.
Another solution is to require to be online when the game is launched, this way you can check time on a remote server.
You could has well check if you got an event on the phone login or wake up react to it, saving the time at that moment in your DB. You would have the last non modified time.
A last possible trick is to check for a file you know is going to be modified by an action prior to time change (such as login), and check the 'last modification' date.
You can investigate in the GPS direction as well. A GPS need to be synchronised with the satellite it contact, so it must keep track of time in some way, and maybe there is an API for that.
Unfortunatly you are on an iphone, which mean your possibilities are limited since applications got very few rights and are sandboxed.
EDIT:
Just though about it but, can you create event in the iphone calendar ? And check if it has been trigered ? Cause you could set a fake meeting or something for every day. Not clean, but creative.
EDIT 2: can you set a timer as a code for IOS to execute in 60 minutes ? If you can, set this timer, pass the time expected to be when this code run, then when the code run, compare and inform your program.
One way to prevent it is to monitor time passing by checking timestamps for their logins in a database. It doesn't matter if the client's iPhone's time is off; the database on your end will still know how long it's been since the last login.
I think if you have internet access you can take the time from a server.
A second solution : You can record the "datetime" and every time you see a "BIG" difference between the record datetime and the running datetime you know there might be a problem.
but this is not elegant, i know.
You can also record a small ammount of datetimes that the application started and check the diffrence with the running datetime.
Also you can use "Activity"->"Datetime" so the "Updates" (levels etc) can't be retaken.
Because the system Datetime can be changed by user, there is potential for "hack".
call a web service to get the time, rather than rely on the phone. There are several places you could get time from, google is your friend i'm sure, or create one yourself, and use the local time of the machine the service runs on for the time.
You could also use the Network Time Protocol (NTP) servers to get a consistent time
Using VB6
I want to compare the system date, if the exe should not work after 02/11/2009
vb6 code
Dim dte As Date
dte = DateValue(Now)
'MsgBox DateValue(Now)
If dte > DateValue("01/11/2009") Then
Unload Me
End If
But if the user change the system date, it will work, my exe should not work after 10 days. How to set.
Need VB6 CODE Help.
There is no 100% secure way of doing this. Usually software doing that encrypts the date into some obscure registry key. But is not in accord with Kerkhoffs' principle.
Generally speaking you would have to persist the installation or first run date somewhere on the system (where users cannot easily modify or delete it) to compare it to the current system data. Beside this you shall protect your program against tampering attacks.
To protect against system time changes there is also no 100% good solution. An easy one would be to look at some files in the profile of the user and take the newest one. If this time is later than the current system time (with some delta), then someone manipulated the datetime settings.
All this is worth almost nothing, as it is really easy to workaround such a protection (even without deep programming knowledge). I would consider a solution in limiting the functionality of your program and protecting your code against tampering (what you have to do anyway, no matter what you choose as a solution).
The amount of effort to implement a truly robust date-based protection system is not proportional to the protection provided.
In any case, the last scheme I used seemed to work. I stored the last run date and number of days left in some obscure registry keys. Each time the app started I checked that last run date key was still in place and had a valid value and I checked the number of days left. Both these values were stored encrypted. To add a level of confusion I read and wrote a number of garbage keys in more obvious locations.
The trial expired if I found evidence of tampering such as changed garbage keys, a current date that was older than the last run date and a few other things.
To slow down users trying to hack the software I encrypted the names of the registry keys in the code so they wouldn't be obvious when the exe was viewed in a hex editor.
Was all that effort worth it? Probably not. I suspect a lot less would have detered most casual crackers and the serious ones, well, they would have cracked it anyway.
I my opinion, it is possible just save time difference between your exe release date and future locking date.
If user system clock is set back than release date give user to set it right and then simply check if exe is running before future locking date.
I think you got it……
Software copy protection is a big subject, and there's many possible approaches, from commercial libraries and hardware keys, to "roll your own" like you're suggesting.
I advise you read some of the other discussions on copy protection on Stack Overflow. E.g. this or this or this.