I have a Ruby script which downloads YouTube Insight reports for specific videos within specific date ranges. It authorizes with ClientLogin, retrieves <entry> XML data for a video, and extracts from that data a URL which points to a CSV report:
http://insight.youtube.com/video-analytics/csvreports
?query={VIDEO_ID}
&type=v
&starttime=1315353600000
&endtime=1317772800000
&user_starttime=1317168000000
&user_endtime=1317772800000
®ion=world
&token={API_TOKEN}
&hl=en_US
The above URL works. However, I want a report for a specific date range, not the default range provided.
An Insight report query's requested date range is set in the user_starttime and user_endtime params. (In the above default case, it's 2011-09-27 through 2011-10-04.) The YouTube API docs say that you can specify your own date range (covering a span of up to 28 days) by substituting timestamps (in milliseconds) that represent the dates you want.
So, why does the following query 404?
http://insight.youtube.com/video-analytics/csvreports
?query={VIDEO_ID}
&type=v
&starttime=1315353600000
&endtime=1317772800000
&user_starttime=1307937600000
&user_endtime=1308110400000
®ion=world
&token={API_TOKEN}
&hl=en_US
The date range looks OK:
ruby > Time.at 1307937600
=> 2011-06-13 00:00:00 -0400
ruby > Time.at 1308110400
=> 2011-06-15 00:00:00 -0400
The fact that the "default" URL works indicates that I must be doing something wrong with these date values, but I can't figure out what. What am I overlooking?
UPDATE 2 -- Nov. 4, 2011:
There has recently been a change to the YouTube Data API Protocol for Insight data, and the answer below is no longer accurate.
YouTube now permits date ranges of up to 31 days for a single Insight report query, and they now allow requests pertaining to dates going back to March 1, 2009. The docs now say:
You can adjust the date range for which a report contains data
to a period of up to 31 days beginning no earlier than March 1, 2009.
This is excellent news. (Leaving the below for posterity.)
I believe I've figured out why the above Insight report query with the custom date range is 404ing. I was able to retrieve a report with a custom date range like this:
http://insight.youtube.com/video-analytics/csvreports
?query={VIDEO_ID}
&type=v
&starttime=1315353600000
&endtime=1317772800000
&user_starttime=1315627200000
&user_endtime=1315972800000
®ion=world
&token={API_TOKEN}
&hl=en_US
What's the difference between this (good) URL and the previous (bad) URL in my question above? Well, my custom date range here, specified in the user_starttime and user_endtime parameters both fall within the range set by YouTube in the starttime and endtime params.
In other words, starttime and endtime seem to represent the outer bounds of any user-specified custom date range possible through these types of requests.
So, when the YouTube API docs say:
You can adjust the date range for which a report contains data to a period of up to 28 days
What they mean, I suppose, is:
Your date range may not span more than 28 days ... AND ALSO ...
Your date range may not fall outside of a date range going back 28 days from the most recent date on which reports are currently available, which we tell you through the starttime and endtime parameters.
UPDATE:
In this thread, a YouTube API Team member says:
You should consider the starttime value the absolute earliest supported start date and endtime the absolute latest supported end date. If you try to set user_starttime to something earlier than starttime then you're going to ask for data that dates back more than 28 days, and that data isn't available.
This exact text should be in the documentation.
Related
In Microsoft Graph Todo Task Item documents (this link) there are two fields with two different names but with the same description: lastModifiedDateTime and bodyLastModifiedDateTime.
Anyone knows the difference of these 2 fields?
You are right, the description on create todoTask is wrong.
If you check todotask resource's properties the bodyLastModifiedDateTime has the correct description.
The date and time when the task body was last modified. By default, it
is in UTC. You can provide a custom time zone in the request header.
The property value uses ISO 8601 format and is always in UTC time. For
example, midnight UTC on Jan 1, 2020 would look like this:
'2020-01-01T00:00:00Z'.
I'm looking to compare the dates of some AWS resources in an external script so I need to match AWS's date/time format.
AWS' own documentation states that the date must be the complete date plus hours, minutes, and seconds, however date formats end up looking like 2017-07-27T15:47:59.373Z, where my hardcoding of %Y-%m-%dT%H:%M.%SZ gets me only 2017-07-15T11:39.29Z.
Side by side, that's:
AWS: ??? - 2017-07-27T15:47:59.373Z
Me: %Y-%m-%dT%H:%M.%SZ - 2017-07-15T11:39.29Z
There's something on the end that's adding a few extra digits. What am I missing to get the formatting identical?
The "extra digits" is the milliseconds.
I'm assuming you're using bash's date command. If that's the case, try with:
date -u +"%Y-%m-%dT%H:%M:%S.%3NZ"
The -u option gets the date in UTC (so it's compliant with the Z, which is the UTC designator).
If you don't use -u, it'll print the date and time in the system's timezone (which can't necessarily be UTC).
The ActionView::Helpers::FormOptionsHelper provides the time_zone_options_for_select to get a list of options for a select control that includes all of the timezones with their UTC offset. The problem I'm having is how to get it to display the correct offset for when daylight savings time is in effect?
For instance U.S. Mountain time is usually -7 UTC but during the summer it's effectively -6 UTC. Is there a way to have that list correctly reflect that?
TL;DR
The time zone data you are receiving is "correct" because ActiveSupport::TimeZone and TZInfo::Timezone instances do not make assumptions about the current date, and therefore applying DST to them doesn't make "sense" in the context of the responsibility of those objects.
You notice the problem because the default model for time_zone_options_for_select, ActiveSupport::TimeZone, unfortunately returns the offset string when calling #to_s, which, if the location is currently is observing DST, will be incorrect. There is no way to fix the string values generated in the options, or even remove the offset from them.
If this isn't acceptable you'll need to skip on using time_zone_options_for_select, and use options_for_select instead, and generate the options yourself.
Some investigation
time_zone_options_for_select uses ::ActiveSupport::TimeZone as the default model parameter, so passing it in manually will not change your results. In order to construct options for a select box, that method will construct an array of tuples in the format of [time_zone.to_s, time_zone.name], for the purpose of passing it to the more generic options_for_select method. time_zone, in this case, is an instance of ::ActiveSupport::TimeZone.
The important factor here is that this time zone instance object is, conceptually, completely unrelated/divorced from the idea of "the current date". The definition of a time zone (strictly speaking) has nothing to do with the current date. We can confirm this "not using DST" issue like so:
::ActiveSupport::TimeZone.all.find { |tz| tz.name == "Adelaide" }.utc_offset
=> 34200 # 9 hours and 30 minutes, in seconds
Adelaide's non-DST time zone is ACST (Australian Central Standard Time) which is GMT+9.5. Currently (as in the time of writing), Adelaide is in DST which means they are on ACDT (Australian Central Daylight Time), which is GMT+10.5.
::ActiveSupport::TimeZone.all.find { |tz| tz.name == "Adelaide" }.now.utc_offset
=> 37800 # 10 hours and 30 minutes, in seconds
The crucial difference here is essentially what I've outlined above - the ActiveSupport::TimeZone instance is just not concerned with the current date. The class itself is a convenience wrapper around a TZInfo::DataTimezone instance, which has similar opinions on the current date - none.
If you noticed, in the second code snippet above, we called #now on the time zone object before calling #utc_offset. This returns an ActiveSupport::TimeWithZone instance, which includes information about the time zone, as well as the current date - and therefore we get an offset which reflects the fact that the current date should include the DST offset.
So, the only problem here is that including the UTC offset string in the return value of #to_s on ActiveSupport::TimeZone instances is sort of misleading in this instance. It's included because it's the "base" UTC offset for that time zone.
Resources:
Rails 6.1 time_zone_options_for_select implementation
Related GitHub issue, rails/rails#7297
Related GitHub pull request, rails/rails#22243
I had similar problem but ended up using this
time_zone_select('time_zone', TZInfo::Timezone.us_zones,
:default => "America/Los_Angeles",
:model => TZInfo::Timezone
Did you find a better solution?
I have the following times stored in an XML document, which correspond to the time when the document was created and then updated:
<create-time>2010-11-04T03:13:35.212Z</create-time>
<update-time>2010-11-03T20:18:26.331-07:00</update-time>
The document was created at 8:13 pm, and then updated 5 minutes later, at 8:18 pm, but when I show the creation dates with format-dateTime(xs:dateTime(.), '[M]/[D]/[Y]'), I get 11/4/2010 and 11/3/2010, as if the document was updated one day before it was had been created, which is obviously not the case. How can I fix this?
The create-time and update-time in your XML document are correct, but they use different timezones:
create-time is in UTC (also called Zulu time, hence the Z).
update-time is in Pacific time.
This can happen if different pieces of code set this the time, or even from the same code using different libraries or functions. For instance, if you are using XPath from XForms:
Using current-dateTime() uses a timezone from the dynamic context, which is often the current timezone for the machine on which the code is running.
Using now() always returns a UTC time.
The solution in XPath is to use the adjust-dateTime-to-timezone() function. This will normalize your dateTimes so they are in the same timezones. As an example, in an XForms output, to show just the date part of create-time you would use:
<xforms:output value="format-dateTime(adjust-dateTime-to-timezone(xs:dateTime(create-time)), '[M]/[D]/[Y]')">
<xforms:label>Creation date</xforms:label>
</xforms:output>
I am trying to create a rss feed from a web page. I am able to get the data to create the title, but I am trying to get the date updated correctly. There is a string on the page, that tells what time of day the news was reported, such as "Time of Report: 1pm". So how can I get the "1pm" and convert that to a date string that contains the current date, with this time?
Thanks,
CP
The Pipes "Date Builder" module is surprisingly powerful.
You can actually feed it a string like "1pm" and it will return:
hour21
timezoneUTC
second0
month1
minute0
utime1264021200
day20
day_of_week3
year2010
The date is relative to when you run it - in this case it assumes "1pm Today". The result is "hour21" in UTC because it parsed in Yahoo's time-zone. So if you need something specific, use the "Sting Builder" to append the time-zone. For example "1pm GMT" gives:
hour13
timezoneUTC
second0
month1
minute0
utime1263992400
day20
day_of_week3
year2010
Obviously you may run into issues if your pipe runs after a date change - an "11pm" entry could easily be read the following morning, leading to inaccurate results.