I'm looking for a profound explanation what exactly the difference between TZOFFSETFROM and TZOFFSETTO in an iCalendar description is and how to calculate it.
While it is described here: https://www.rfc-editor.org/rfc/rfc5545#section-3.6.5 [Page 65] I can't wrap my head around the meaning and especially how to calculate it.
I have a list of all timezones and their related UTC_offset_StandardTime and UTC_offset_DaylightSavingTime but there is no "…onset…"-time.
While there is a somehow answer https://stackoverflow.com/a/3872214 I can't find a resource which proves that this right.
What am I missing?
Re: "How to calculate the timezone offset":
It is not 'calculated', but rather looked up - most systems have this information built in using the Olson timezone database, and kept (hopefully) up to date. The systems or languages usually have a function to get the offset for a given date and time. EG:
in php https://www.php.net/manual/en/datetime.getoffset.php. or one can get all the transitions to output to a VTIMEZONE https://www.php.net/manual/en/datetimezone.gettransitions.php
general comment here https://en.wikipedia.org/wiki/Time_zone#Computer_systems
Most systems maintain such a db. Usually there is a recurring rule that always is so, however countries and areas may change the date of daylight saving change. See https://en.wikipedia.org/wiki/Daylight_saving_time_in_Australia#Western_Australia and changes made for the Olympics. This would mean an extra set of VTIMEZONE DST transition definitions for those areas, with DTSTARTS and UNTIL's on any recurring rules to indicate over what years they apply or do not apply.
Now the .ics specification says we must include these timezone transitions - the daylight saving changes in a VTIMEZONE definition in the file.
That leads us to your other question:
RE: what is TZOFFSETFROM and TZOFFSETTO?
They are literally for each transition date generated by the RRULE (or just a date if not recurring if it was a one-off), relative to UTC or GMT:
the OFFSET FROM which a daylight saving change is coming and
the OFFSET TO which a daylight saving change is going
Take the New York 2021 daylight savings change on 14 March. The timezone offset is -5. After 14 march 2021 2 am, the timezoneoffset will be -4. See https://www.timeanddate.com/time/zone/usa/new-york-state.
So If we look at what google calendar outputs, we see that on the second sunday of march at 2am, Daylight saving begins, NY goes
FROM -05 and
TO -04.
Then when they revert to Standard Time on the 1st sunday in November, NY goes
FROM an offset of -04 and
TO an offset of -05.
NOTE that both (a FROM and a TO offset) are required because the change is NOT always by an hour. Sometimes the change may be 30 minutes. See https://www.timeanddate.com/time/time-zones-interesting.html and scroll down near the bottom. You'll see Lord Howe Island had a 1/2 hour change and further down under 'Historic half hour offsets' what North Korea did in 2015 and Venezuela in 2016.
Google Calendar New York example:
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
Related
UIKit provides TimeZone.secondsFromGMT() method which simply returns the number of seconds from the GMT time.
The function returns incorrect value as of 27th of Oct, when Europe moved off of the summer time (CEST-> CET). It currently returns 3600, and prior to the 27th of Oct, it returned correctly 7200.
This function should always return constant value of 7200 irrelevant of current timezone (Daylight savings change timezones, not timezone itself). Even if Europe went to the CET time during the winter, CEST time didn’t change (Europe just doesn’t “use” it now).
This behavior breaks my unit tests and therefore correctness of the app.
Effectively this should always pass:
let timeZone = TimeZone(abbreviation: "CEST")!
XCTAssertTrue(timeZone.secondsFromGMT() == 7200)
Am I thinking about this incorrectly?
Your misconception is here:
(Daylight savings change timezones, not timezone itself). Even if Europe went to the CET time during the winter, CEST time didn’t change (Europe just doesn’t “use” it now).
What you are talking about, are offsets. TimeZone objects are capable of representing offsets, namely by creating one using the init(secondsFromGMT:) initialiser. In most cases though, thinking in terms of timezones, such as Europe/Paris is more useful.
init(abbreviation:) simply looks up the string you passed in the TimeZone.abbreviationDictionary, and uses the looked-up value as the timezone identifier. With a simple inspection, you will see that in the dictionary, CEST corresponds to the value Europe/Paris.
The identifier Europe/Paris represents the timezone adopted by France. The TimeZone object created with this identifier encapsulates, among other things, all the historical offset transitions, and the transition rules for future transitions (e.g. "DST ends on the first Sunday on or after 25 Oct").
In other words, a TimeZone object is not just a number of seconds from GMT. It is more like a mathematical function, mapping points in time to local date times. This function would mostly be continuous, except in those points in time where an offset transition happens.
If you just want a constant offset of 7200 seconds, do:
TimeZone(secondsFromGMT: 7200)
I'm creating a customized function that does some calculations for a given time.
When a time is entered in a cell, for example 4:00 PM, this is automatically converted into a date, in this case 12/30/1899 16:00:00 and when the function getTheMinutes() is called, it returns 2 instead of 0.
function getTheMinutes(dateTime){
return dateTime.getMinutes();
}
The behavior of the function is different if it's used for a most recent date like 5/1/2019 16:00:00.
I want the user to be able to just write a time in a cell then use the customized function in another cell. Please let me know your thoughts.
Now that you have indicated the time zone for your spreadsheet I can confirm what #RobG deduced almost a day ago, which is that Guatemala adjusted its difference relative to UTC. Something you have confirmed is treated as by two minutes with effect from October 5, 1918.
More specifically, the adjustment was of 2 minutes and 4 seconds and effective from 03:00 that day:
(Source IANA Version 2019b file northamerica.)
There have been very many such minor adjustments around the world over the years (even between towns in the same country) and adjustments continue, though usually of a whole hour – between 'standard' and Summer time. Sheets has very properly recognised that "normal arithmetic" 'does not work' across such a transition and while noon yesterday to noon today for example is normally, for any one specific location, a difference of 24 hours it is often 23 hours or 25 hours on the day that clocks go forward/back.
And the moral of the story is to beware of obliging Sheets to assume, for want of a specific date, that is has the index number 0 - i.e. is December 30, 1899.
I made some testing, and I found out that the formula is giving a wrong result any minute before 10/5/1918 0:03:00, from that DateTime on, the formula is working as expected.
Here is my sheet https://docs.google.com/spreadsheets/d/1psm8_GJYRczO53TILJCOzo0p4GpnS-ooiGWqOJrC8ZU/edit?usp=sharing
I would need to do a date validation in my customized formula to make it useful. I don't know why google sheets is choosing that date as default when just a time is typed in a cell, I think it should be improved.
How do I get date function to return date according to current system date?
Right now, with the code snippet below, it always returns UK time, not the current system date.
<calculate>
<script>$ = concat( num2date(date(), DateFmt()), " ", num2Time(Time(), TimeFmt()) )</script>
Any help is appreciated!
It's probably not UK time exactly, but rather GMT (or UTC, to use a more precise term). The UK happens to be aligned to GMT in the winter, but in the summer it advances one hour to BST for daylight saving time.
Now, I've never used LiveCycle myself, but nonetheless, I've read through the somewhat minimal docs for LiveCycle FormCalc Date and Time Functions, and the spec, and it appears to me that a few critical mistakes were made.
The date and time functions return UTC-based values, but only the time-related functions have been made aware of the local time zone. That is, there are separate Num2Time and Num2GMTime functions, but there is only one Num2Date function.
The Num2Date function works in terms of whole integer days, and thus they are simply days since 1900-01-01. Therefore, the number being passed in to the function must already be representative of the desired time zone. However, the Date function only gets the current GMT date. There does not appear to be a function to get the current local date.
It's different on the time side, because of the millisecond precision involved. However, there's yet another flaw here. Despite the docs saying that the Time function returning "the number of milliseconds since the epoch", its actually returning only the number of milliseconds since midnight GMT. There is no day-over-day accumulation of milliseconds from the date part. The docs here are even lying in their sample code which says:
Returns the current system time as the number of milliseconds since the epoch.
Time() => 71533235 at precisely 3:52:15 P.M. on September 15th, 2003 to a user in the Eastern Standard Time (EST) zone.
If that was indeed the case (and ensuring to use their 1900-01-01 epoch), the value would actually include an additional 3272572800000 milliseconds representing the days between 1900-01-01 and 2003-09-15, bringing the total timestamp to 3272644333235. Additionally, there's a typo there, because the timestamp they give is 3:52:13, not 3:52:15. Clearly nobody paid close attention to these docs!
The real problem is that one cannot be certain that the number of milliseconds since midnight of the current day in the local time zone is the same on every day. If instead of getting the current time, you were working with past stored time values, you might be an hour off (+ or -) if the current offset is different due to daylight saving time. Example: Eastern time might be UTC-5 or UTC-4, but only the offset currently in effect will be used by the Num2Time function, even if the date you're working with is using the other offset.
So, in summary, the Date function is insufficient, leading to your observations, and the date/time functionality in general is poorly designed. Given the constraints of this API, I can't even recommend a workaround. There would have to be a LocalDate function of some kind to be used instead of the Date function, but it doesn't exist.
The only advice I can offer is that it appears (from my research, not experience) that LiveCycle can use either FormCalc or JavaScript. So - use JavaScript instead.
I've been working on facebook application. But I've faced with strange bug(?).
It I'm trying to get detailed info about any event using graph api start_date differs from the one if I'm trying to get it using fql. for example:
https://graph.facebook.com/209798352393506/ - start date is 2011-05-26T19:00:00
https://api.facebook.com/method/fql.query?query=select%20eid%2C%20name%2C%20tagline%2C%20pic%2C%20host%20%2C%20start_time%20from%20event%20where%20eid%20%3D209798352393506 - start time is 1306461600. Which in human readable format equals to Fri, 27 May 2011 02:00:00 GMT.
As you can see difference between got dates is 5 hours. Somtimes I'm getting dates which differ for 8 hours, sometimes - 6.
Correct date is the first one:
http://www.facebook.com/events/209798352393506/
I can't figure out what happens. All events I'm trying to view are from Denmark. My timezone is Europe/Kiev. Difference is 1 hour.
Is this a facebook's bug? Or documented feature? Or am I doing something wrong?
Link to the documentation or another answer in stackoverflow would be enough.
Here is two events
http://www.facebook.com/events/290600150977115/ - starts on 2012-03-22 at 20:00
http://www.facebook.com/events/289501924395338/ - starts on 2012-03-03 at 21:00
But. Using FQL I'm getting that first event starts on 2012-03-23 at 04:00. Difference is 8 hours. And the second one starts on 2012-03-04 at 06:00. In this case difference is 9 hours. Why???
It was because of daylight saving time.
Time difference between me and facebook(Los Angeles) sometimes was 8 sometimes 9 hours, because there was a moment when Denmakr alredy changed their time to summer time and los angeles - not.
The problem occured when event started "in winter time" and finished in summer time. In this case I needed to add one hour.
Facebook is weird.
From /fql/insights/
The end of the period during which the metrics were collected, expressed as a unix time (which should always be midnight, Pacific Daylight Time) or using the function end_time_date() which takes a date string in 'YYYY-MM-DD' format.
2011-05-26T19:00:00 ===> 2011-05-26T19:00:00 PDT ===> Fri, 27 May 2011 02:00:00 GMT.
I don't understand the way the API returns values. Here's a sample of a page_impressions call, with 'week' as the period.
"values"=>
[{"end_time"=>"2012-01-08T08:00:00+0000", "value"=>1116},
{"end_time"=>"2012-01-09T08:00:00+0000", "value"=>1171},
{"end_time"=>"2012-01-10T08:00:00+0000", "value"=>1175}]
It seems that they're showing how many hits I had in the last 7 days up to the date in "end_time", is that correct? If it is, then I don't understand what use this would have, there is a huge overlap in the data.
How can I get the number of impressions of the last weeks instead? And how can I get more than 3 values to display? I really can't understand the logic behind this or how it could be useful.
What's happening here is that you're being given the total number of page_impressions for the 7-day period ending on each of the dates shown (i.e., how many times was the page seen over the past 7 days assuming the week ended on the end_time? and then on end_time+1? end_time+2)
Facebook is returning three (3) separate readings, presumably so you can spot/review very local trends (e.g., "are my weekly impressions creeping up?) or perhaps because you missed a measurement and want to have values for every day.
To answer your question specifically:
The 7-day period 2012-01-01 through 2012-01-08 12:00am* had 1,116 impressions.
The 7-day period 2012-01-02 through 2012-01-09 12:00am* had 1,171 impressions.
The 7-day period 2012-01-03 through 2012-01-10 12:00am* had 1,175 impressions.
As is quoted below, the end_time itself is always midnight in PDT. Thus, an end_time of 2012-01-08 really means the measurement stopped the night before, i.e., at 1 minute past 11:59pm on 2012-01-07.
From https://developers.facebook.com/docs/reference/fql/insights/:
The end of the period during which the metrics were collected,
expressed as a UNIX time (which should always be midnight, Pacific
Daylight Time) or using the function end_time_date() which takes a
date string in 'YYYY-MM-DD' format. Note: If the UNIX time provided is
not midnight, Pacific Daylight Time, your query may return an empty
resultset. Example: To obtain data for the 24-hour period starting on
September 15th at 00:00 (i.e. 12:00 midnight) and ending on September
16th at 00:00 (i.e. 12:00 midnight), specify 1284620400 as the
end_time and 86400 as the period. Note: end_time should not be
specified when querying lifetime metrics.