yes this is an iOS programming question.
I need to calculate the exact time the RMS Titanic sank for its 100 yr anniversary.
It sunk at 15th April 1912 2:20 a.m.
Stupid Question you say. 100th year anniversary is
15th April 1912 2:20 a.m.
+100 years
15th April 2012 2:20 a.m.
But I want an alarm to go off in any timezone in the world exactly and need to handle timezones, and things like British Summer Time being one hour ahead yet it didnt come into effect till 1918.... but as of today 25 mar 2012 London IS in BST so one hour ahead.
Im confused on timezones. We have GMT and UTC. The ships sank at 49° 56' 49" W, 41° 43' 32" N so few hours ahead of London.
-49.94822196927015
41.72713826043066
Whats the correct way to enter a historic date into NSCalendar
and to add 100 years to it exactly and get back the right time
in the users current timezone?
I notice theres Japanese and Islamic calender formats in NSCalendar options. Can iOS device change their dates to these calendars?
And if this was the case. how would I convert from Gregorian to say Islamic?
nice brain puzzler to start your week :)
(There's no code here, as I've never used the iOS API. However, I have some experience of date/time APIs and the oddities they throw up, so I hope you find this answer useful anyway.)
What's the correct way to enter a historic date into NSCalendar
and to add 100 years to it exactly and get back the right time
in the users current timezone?
It really depends on what you mean by "100 years" - it's not like that's a fixed amount of time really.
I would take the UTC instant at which it sank, apply the user's local time zone, and then add a hundred years to that. However, you then need to consider that the result may not actually be a valid local time in that time zone.
For example, suppose you're in a time zone where at the instant of the sinking, it was 1:20am... but in that time zone, 15th April 2012 is when the clocks change - and they skip from 1am to 2am. In that case, 1:20am never occurs... so you could potentially pick 12:20am, the instant before the DST transition, the instant of the DST transition, or 2:20am, depending on what you think is appropriate.
Another possibility to consider is the opposite - suppose it's a DST transition which goes from 2am to 1am... so 1:20am actually occurs twice. What would you want to do in that case? You probably shouldn't make your app celebrate the anniversary twice!
Another option which removes this possibility of ambiguity and discrepancy is to work out what the offset from UTC in the user's time zone was at the exact time of the sinking, then add 100 years to the UTC value (which will never have any DST transitions) and apply the same offset again.
I notice theres Japanese and Islamic calender formats in NSCalendar options. Can iOS device change their dates to these calendars? And if this was the case. how would I convert from Gregorian to say Islamic?
I don't know on that front, I'm afraid.
Related
I need to parse strings with time like '09:21:15 EST' (where EST is US Eastern timezone), so that the information about summer / winter time (daylight saving time) is correct, so that UTC−05:00 is used for winter dates, and UTC−04:00 for summer dates.
It is also necessary to support the direct setting of the UTC offset - '09:21:15 UTC−04:00', in which case daylight saving time should not be taken.
I Didn't find anything intelligible and sensible in Qt documentation for QDateTime, QDate, QTime, QTimeZone etc.
Is there an easy way to solve this problem?
In general, in any language, what you ask cannot be done reliably.
EST is not a time zone. It's an English abbreviation for an aspect of a time zone.
There are places that use EST without EDT, such as Jamaica for example. See more here.
There are non-English abbreviations to consider, such as HNE that's used in places in French-speaking Canada such as Montréal.
Many abbreviations are ambiguous. For example CST could be Central Standard Time, Cuba Standard Time, or China Standard Time.
Many time zones don't have any abbreviation - even in English. They are sometimes given invented (made up, artificial) abbreviations that aren't legal or in common usage, but in reality they are referred to by their country name or only by their UTC offset (for a given timestamp).
In order to convert between time zones reliably for multiple timestamps, you need an IANA time zone identifier, such as "America/New_York". QTimeZone can work with these.
On any given timestamp you can have an offset from UTC, such as -05:00. You can set an offset when using QDateTime.
If you are absolutely sure you are only working with timestamps from North America containing common English abbreviations, you could build and use an opinionated mapping between string and offset, such as "EST" == -5, "EDT" == -4, "CST" == -6, "CDT" == -5, etc. But it can only map abbreviation to offset, not to a time zone. (See also "Time Zone != Offset" in the timezone tag wiki.)
Qt likely has the features you need already implemented.
With QDateTime::fromString you can use t in the format string to mark timezone characters.
Have a look into this question as well: Qt QDateTime from string with timezone and daylight saving
There you can get an example, which shows that you need the QDateTime in the LocalTime specification to be able to deal with daylight saving times.
However, QDateTime::offsetFromUtc is dependent from the QDateTime's current specification...
I guess, you would need to always convert the QDateTime object to the same TimeSpec before comparing offsetFromUtc
Kusto provides functions to get the start- and end-day of the week. These are invoked through startofweek() and endofweek(). startofweek() returns Sunday, and endofweek() returns Saturday.
In some countries, weeks are from Monday to Sunday, which I have been unable to locate how to change.
Is it possible to set the culture in kusto, such that startofweek() and endofweek() would return Monday and Sunday respectively?
No, I have not seen a setting where culture can be set in Kusto. Where operating systems and applications which make it possible to set such configurations, I see Kusto being being fairly basic and similar to .NET libraries where the DayOfWeek enum begins with Sunday at index 0 and there is no way to change that foundation.
The documentation indicates that "Start of the week is considered to be a Sunday." so I believe that is that. It is up to us users to adapt from there. (https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/startofweekfunction)
I'm sure you have done this yourself already, but here has been my approach.
startofweek(now()) + 1d
endofweek(now()) + 1d
I am updating an application to use NodaTime to fix many existing time issues with our data and processes.
I will need to resolve timezones from a mobile app that sends IANA timezone names. I will need to support conversions to UTC using custom offsets (i.e. hard coded -04:00). I may or may not need to support Windows timezone names as well.
For all of this, I am wondering if I need additional packages. How do TimeZoneConverter and TimeZoneNames work alongside NodaTime? Are there any other additional packages I should use alongside NodaTime?
Our ultimate goal is to get all data persisted as Utc and convert to/from user time only for display or accepting user input.
You don't need any extra packages for that scenario, as far as I can see.
For IANA IDs, just use DateTimeZoneProviders.Tzdb
For "raw offset" IDs, you can use any time zone provider, asking for an ID of the form "UTC+01:00" etc. (So you'd need to add the "UTC" prefix.)
For Windows zone mapping, you can use TzdbDateTimeZoneSource.Default to get the default TZDB information, then use the WindowsMapping property to get a WindowsZones object you can use for mapping.
TimeZoneConverter may well be simpler to use for the last bullet point, but it's not required. The IANA IDs it provides should work fine with Noda Time.
TimeZoneNames is more about displaying time zone names to users. If you don't need to do that, you probably don't need the package.
Note that persisting all data as UTC may be a really bad idea - it's hard to tell without knowing more about your application. If you only deal with values in the past, or if they're fixed instants in time, that's fine. But if you're allowing users to schedule future events, I'd store the values that the user gave you. Here's an example of why...
Suppose the user says they want to schedule an event for Europe/Paris at 9am on December 1st 2021. If you convert that to UTC now, you'll end up with 2021-12-01T08:00Z, because the current time zone rules say that Paris will be at UTC+1 in December 2021.
However, it's entirely possible that between now and 2021, France will have changed its time zone rules to be on "permanent daylight time", i.e. UTC+2 all year round. At that point, your UTC value of 2021-12-01T08:00Z would correspond to 10am in Paris on the given date - contrary to what the user specified.
It's fine to convert to UTC as well so that you can create a totally ordered view of the data, so long as you retain enough information to perform that conversion again every time there's new time zone data.
As I say, that may not be an issue for you, but it's worth knowing that the "received wisdom" of "Always store everything in UTC" is really not good advice for all scenarios.
My boss asked me to perform a T-Test to test the significance for a certain metric we use called conversion rate.
I have collected 18 months worth of data for this metric dating April 1, 2017 - September 30th, 2018.
He initially told me to collect 12 - 14 months of the data and run a t-test to to look for significance of the metric. (Higher conversion rate means better!).
I'm not really sure how to go about it. Do I split the data up into 9 month samples i.e. Sample 1: April 2017 - December 2017, Sample 2: January 2018 - September 2018 and run a two sample t-test? Or would it make sense to compare all of the data against a mean like 0?
Is there a better approach to this? The bottom line is he wants to see that the conversion rate has significantly increased over time.
Thanks,
- Keith
My advice is to dump the t-test and look only at the magnitude of the change in the conversion rate. After all, the conversion rate is what's important to your business. By the way, looking at the magnitude of something practically relevant is called "effect size analysis"; a web search for that should turn up a lot of resources. To get started, just make a plot of the available data -- is conversion rate going up or going down or what?
Further questions should be directed to stats.stackexchange.com instead of SO. Good luck and have fun.
I am doing this
datediff = (date1 - DateOfDeposit).TotalDays;
But this gives the no. of days and I want no.of months.
The simplest option is probably to use my Noda Time library, which was designed for exactly this sort of thing (as well as making it cleaner to work with dates and times in general):
LocalDate start = new LocalDate(2013, 1, 5);
LocalDate end = new LocalDate(2014, 6, 1);
Period period = Period.Between(start, end, PeriodUnits.Months);
Console.WriteLine(period.Months); // 16
There's nothing built into .NET to make this particularly easy. You could subtract years and months as per Ani's answer, but then also take the day of month into account to avoid the issue I describe in comments. I'd suggest writing a good set of unit tests first though - bearing in mind leap years and the like.
Assuming you want the number of whole months, I think this should work (not sure what corner-cases this doesn't handle, but can't think of any off the top of my head):
12 * (date1.Year - DateOfDeposit.Year) + (date1.Month - DateOfDeposit.Month)
You could always add any fractional component with DateTime.Day, but it's not clear how that should precisely be defined (how many months are between Jan 29 and Feb 27?).
If you're doing a lot of date-time handling, Jon Skeet's Noda Time library (that he mentions in his answer) is a good choice.