I'm pulling a timestamp out of a UIDatePicker like so:
datePicker.date.timeIntervalSince1970
The timestamps are always off by a seemingly random number of seconds. Given that the UI specifies a whole number of minutes, I'd expect that number to be divisible by 60. For example here's what I just got out of the debugger:
(lldb) po self.datePicker.date.timeIntervalSince1970
1396655124
That number corresponds to Fri, 04 Apr 2014 23:45:24 GMT. Where did the 24 seconds come from?
Per wikipedia, "[b]etween their adoption in 1972 and June 2012, 25 leap seconds have been scheduled, all positive."
I'd assume that's where the extra seconds have come from.
Related
I have a GSheet looks like as follows -
TimeSpent
Date.
15 Minute
26 May 2021
20 Minute
26 May 2021
05 Hours
26 May 2021
40 Minute
25 May 2021
20 Minute
24 May 2021
03 Hours
23 May 2021
02 Hours
20 May 2021
Queries -
(1) Wanted to calculate total time spent for today's date(Current date)
(2) There are two different units of time - Minutes and Hours.
try:
=TEXT(SUM(FILTER(IF(REGEXMATCH(A:A, "Hours"),
REGEXEXTRACT(A:A, "\d+")*60,
REGEXEXTRACT(A:A, "\d+")*1), B:B=TODAY()))/1440, "[hh] \Hour\s mm \Minut\e\s")
Date difference is zero today. When comparing Nov 04 and Nov 05, rare issue happening only for today.
Code I'm using
let dayDiff = Calendar.current.dateComponents([.day], from:businessDate , to: today).day!
Ipad date and time set to automatically.
Tried restarting iPad.
Tried setting date to tomorrow and I get date diff 1.
Is there any issues because of changes in day light savings yesterday?
If so, what settings I have to update in order to work it as expected?
Note: We can fix it with code changes, but like to know any iPad settings will fix this problem.
In any timezone that had a change in daylight saving time during that period (such as the in USA), the difference between 2018-11-04 00:00:00 UTC and 2018-11-05 00:00:00 UTC is only 23 hours which is less than 1 day so you get a difference of 0 days.
If you create those dates with midnight local time instead of UTC time, you will get the expected result of 1 day difference.
Or if you use a calendar set to the UTC timezone to calculate the difference, you will get 1 day difference.
I have a start_at, a decimal quantity and an interval which is one of day | week | month | year.
start_at = Time.parse('2016-01-01 00:00:00 UTC') # leap year
quantity = BigDecimal.new('1.998') # changed from 2.998, should end on 2/29/16 sometime
interval = 'month' # could be any of day|week|month|year
With whole numbers, I've used duration i.e. 1.month, and I looked at Date#advance, though it only recognizes integer values.
It would seem simple but I cannot find anything in the standard libraries or in ActiveSupport.
References:
SO answer potentially used for input to Date#advance?
SO explanation of duration
Question
How can I establish the end_at date from a decimal?
Why? What purpose?
Proration to the second for a given amount and given interval.
Expectations
I'm looking for an end_at to the second as accurate as possible with respect to advancing the next interval(s) by the decimal quantity. Given interval = 'month', for the fractional part, when you pass the start of the month, means you are in that month and using it's duration. For example, January 2016 is 31 days, while February (leap) is 29 days (only in the leap year).
I'd say your best option is to use Ruby's date methods to advance time based on the whole number of the decimal, then calculate how many seconds your fraction is of your current interval.
So for 1.998 months, advance time 1 month. Find the current month you are in and get the .998 of the seconds in that month (i.e. for July, 31x24x60x60x.998) and then advance time that many seconds.
What does advancing time a fractional month mean?
Lets say we have the following date 2015-01-01 00:00:00 UTC. It is easy to advance exactly 1 whole month, we simply increment the number that represents months: 2015-02-01 00:00:00 UTC. Alternatively, we could view this as adding 31 days, which we know is the number of days in January.
But what if we want to advance 0.5 months from 2015-01-01 00:00:00 UTC?
We can't just increment like we did when advancing a whole month. Since we know January has 31 days, perhaps we could just advance 15.5 days: 2015-01-16 12:00:00 UTC. That sort of works.
How about 1.5 months from 2015-01-01 00:00:00 UTC? If we combine our previous approaches, we'd first increment, getting us to 0.5 left to advance and 2015-02-01 00:00:00 UTC. Then we'd take half of 28 and get to 2015-02-15 00:00:00 UTC.
But wait, what if instead we took the total number of days between the two months and then took 3/4 of that? Like 2(month) * (3/4), which would simplify to (3(month)) / 2, or 1.5(month). Lets try it.
(28 days + 31 days) * 0.75 = 44.25 days
Now adding that to 2015-01-01 00:00:00 UTC we get 2015-02-14 06:00:00 UTC. That's three-quarters of a day off from our other answer.
The problem here is that the length of a month varies. So fractional months are not consistently definable.
Imagine you have two oranges. One contains a little bit more juice than the other (perhaps 31ml and 29ml of juice). Your recipe calls for the juice of 1.5 oranges. Depending on which one you decide to cut in half, you could have either 44.5 ml or 45.5 ml. But if your recipe calls for 40 ml of orange juice, you can pretty consistently measure that. Much like you can consistently (kind of) increment a date by 40 days.
Time is really tricky. We have leap seconds, leap years, inconsistent units (months), timezones, daylight saving time, etc... to take into account. Depending on your use case, you could attempt to approximate fractional months, but I'd highly recommend trying to avoid the need for dealing with fractional months.
I am writing a Google Calendar sidebar gadget to keep track of the total hours per event tag (as determined in details of the event i.e. "tags: work").
Users can change the current week, month, day they are viewing in the calendar and I want to be able to count up the hours pertaining to their current view.
I don't see anywhere in the gadget API (or any other Google Calendar API) that allows gadgets to access the currently displayed view. I have noticed that the URL has an anchor tag that looks like
g|week-2+23127+23137+23131
which corresponds to viewing Monday Feb. 23, 2015 - Sunday March 1, 2015 in week mode.
I have also noticed the following relationships:
23127 is the first day in the view
23137 is the last day in the view
23131 is the day selected in the month view (on the left of the calendar)
If there is a way to get the currently displayed view using the API, that would be ideal but I would settle for parsing the anchor tag. Unfortunately I cannot decipher how the numbers work.
Google API
The currently displayed date range can be accessed using the following call:
google.calendar.subscribeToDates(function(d) {
// do something
});
where d is a Google date range d.startTime and d.endTime being the beginning and end.
Numbers
The numbers in the URL do not correspond directly to epoch date and time. Rather, each year has 512 days associated with it and each month has 32 days. For example, February has 28 days regularly but every leap year it has 29. The calendar never has to adjust for this since it simply allots each month 32 days and comes out with a nice even number every time.
A careful examination of the date ranges displayed will also show you that if you subtract the number for December 31 from January 1 you get 130. Accounting for the beginning and the end (don't count December 31 and January 1) will give you 128.
12 * 32 + 128 = 512 -- 12 months a year, 32 days a month and a 128 gap per year
Also, for some reason January 1, 1970 has the associated number of 33 so add that to your calculations when determining dates.
This wouldn't fit in the comments, but here's how the encoding works:
The encoding scheme makes it easy to find the day/month/year from the number.
Take 23131 which yields Feb 27, 2015 (from the example in your question).
Divide by 512 and add 1970 (epoch) for the year.
23131 / 512 = 45.xxx => 45 + 1970 = 2015.
Get the remainder of that division and divide by 32 to find the month.
23131 mod 512 = 91 / 32 = 2.xxx = February
Get the remainder of that division and it's the day.
91 mod 32 = 27
Delphi Xe, Win 7, System TimeZone UTC+4:0, The first day of week in system - Monday, Time is synchronised with time.windows.com
In a palette of standard components Delphi Win32 there is component MonthCalendar, at it property WeekNubers=true (display of numbers of weeks), date=now, the first day - Monday.
Shows on 19 number (today) - number of week 43.
I request number through dateutils.WeekOfTheYear(now) = returns 42.
Source (0.5 Mb) http://www.sendspace.com/file/yuz6ko
Judging by an initial code of component MonthCalendar - there like all it is true (even if not to expose the first day of week, it takes value from system parametres).
And in inquiry WeekOfTheYear it is told, that all is considered also standard ISO applied, but numbers do not coincide :(
In any way I will not understand, where one week disappears - if to look on a calendar, should be 43 and if to consider, that weeks 53 and the first concerns last year...
By the way WeekOfTheYear on 01.01.2011 too returns 52 though like should return 1...
Why distinctions and where it is correct?
Both results are correct, the difference is because the DateUtils.WeekOfTheYear function uses the ISO 8601 standard definition of a week. That is, a week is considered to start on a Monday and end on a Sunday.
Check this explanation about the Weeks Numbers in the ISO 8601 format.
If 1 January is on a Monday, Tuesday, Wednesday or Thursday, it is in
week 01. If 1 January is on a Friday, Saturday or Sunday, it is in
week 52 or 53 of the previous year (there is no week 00). 28 December
is always in the last week of its year.
Also the Embarcadero online help for the DateUtils.WeekOfTheYear function says
....if the first calendar day of the year is a Friday, Saturday, or
Sunday, then for the first three, two, or one days of the calendar
year, WeekOfTheYear returns the last week of the previous year.
Similarly, if the last calendar day of the year is a Monday, Tuesday,
or Wednesday, then for the last one, two, or three days of the
calendar year, WeekOfTheYear returns 1 (the first week of the next
calendar year).
So due which the 01-01-2011 was Saturday this week is considered the week number 52 of the previous year.
And that also explains why the week number returned for today (19-10-2011) is 42 instead of 43.
First of all, I could see no difference between the week numbers in the TMonthCalendar component and those returned by DateUtils.WeekOfTheYear(). (Monday is the first day of week on my system.) Both show 42 for the current week and 52 (not 53) for the week of 2011-01-01. (It's 53 for 2010-01-01, so maybe you just mixed that up.)
Now, as to why it's 52 or 53, but not 1, well, it's according to the definition of the first week by ISO:
First week is the week with the year's first Thursday in it.
So week number 1 in 2011 starts on 2011-01-03, and the previous one belongs to the previous ISO year.
The TMonthCalendar can treat the last week of the year as the first week of the next year, WeekOfTheYear function does not do it, hence the difference.
For example according to TMonthCalendar, 1 Jan 2012 belongs to both last week of 2011 and first week of 2012; 2 Jan 2012 is the first day of the second week of 2012.
According WeekOfTheYear function, 1 Jan 2012 belongs to the last week of 2011 only; 2 Jan 2012 is the first day of the first week of 2012.
Monday is the first day of the week for me.