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'.
Related
I need a hand here
The default OutSystems timezone is UTC
There's an Action called ConvertFromTimeZone(1,2,3)
1- You write the Date and Time, no problem here.
2 & 3 - You have to write the SourceTimeZone and the DestinationTimeZone, these must be written in Text data type.
My question is: How exactly am I supposed to write it?
Thanks.
you can use GetSystemTimeZones to get the list of available timezones in the servers.
This post http://www.outsystems.com/forums/discussion/16005/convertfromtimezone/#Post67485 shows the Identifier that uniquely identifiers a timezone.
Just one correction: the default timezone isn't UTC, but the timezone set in your application server.
The value you should use in the timezone code must be one of Microsoft Time Zone Index Values (column 'Name Of Time Zone')
You can find more information about timezone conversion here:
http://www.outsystems.com/forge/component-discussions/500/Time+Zone
you can use this action ConvertFromUTC(UTC_Datetime, "GMT Standard Time") it is from the Timezone extension.
Is there an object that's part of standard Windows 7 that allows us to, within VBScript, get the local time in a given city/time zone?
One approach would be to use something like SWbemDateTime to convert a given time zone to UTC then re-convert back to another zone. Only the methods necessary to effect the latter step are not present on this particular object.
Check out WMI class 'Win32_ComputerSystem' (http://msdn.microsoft.com/en-us/library/aa394102(v=vs.85).aspx) property 'CurrentTimeZone' which returns the current
time in UTC format.
Also the following classes could be referenced for UTC format:
Win32_Timezone - http://msdn.microsoft.com/en-us/library/aa394498(v=vs.85).aspx
Win32_UTCTime - http://msdn.microsoft.com/en-us/library/aa394510(v=vs.85).aspx
Win32_LocalTime - http://msdn.microsoft.com/en-us/library/aa394171(v=vs.85).aspx
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.
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>