OutSystems TimeZone Conversion - time

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.

Related

Difference of lastModifiedDateTime and bodyLastModifiedDateTime in Microsoft Graph todo task apis

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'.

How to get date and time in one place given the date and time in another place

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

Validate Start Time With Current Date In Sharepoint?

I have a column called Start Time (it's a SharePoint Default Calendar Column). I need to validate if the Start Time is less than today or not? Without using javascript? Is this possible?
I have tried this:
Created a column called Today type as Date and Time.
Default value is current date.
Then compared the Start Time and Today in validation settings like the following:
=[Start Time] < [Today]
it seems not working. help please?
Try this code instead of yours
=[Start Time]<NOW()
I use this to validate that Start Date must be less than or equal to Today:
=[Start Date]<=Today()
...and it works for me.

How to get time_zone_options_for_select with DST offsets?

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?

How can I normalize dates stores using different timezones in XPath?

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>

Resources