If I have a date in YYYYMMDD format how to validate in Xquery version "1.0", so that it checks for month and year are valid and if say they are valid then a leap year with month as 02 can have a date 29 else a max 28.
Several integration tools such as Oracle Fusion Middleware implement Xquery version "1.0" not "3.0"
First of all, although your use case is rather simple: generally avoid tampering with dates (and especially times) on your own, and always rely on already implemented functionality, handling date and time is horribly complicated if you want to do it right.
Convert the string to a representation that XQuery's date functions are able to parse. If you can construct a date from the string, it is valid; if an error occurs, it is invalid. Dates can be constructed using xs:date($string). One way to convert the string would be using using substring(...) and string-join(...):
xs:date(string-join((substring($date, 1, 4), substring($date, 5, 2), substring($date, 7, 2)), '-'))
To catch an error, use a try/catch block.
Related
In a Power Automate / MSFlow flow, I receive a string like this:
Saturday, July 31, 2021 1:35 AM | (UTC+01:00) Dublin, Edinburgh, Lisbon, London
I need to convert it to the format Sharepoint expects, i.e. a ISO 8601 for UTC:
YYYY-MM-DDTHH:MM:SS
I painfully built a flow that does most of the work; however, at the thought of having to manually manage the timezone offset my heart finally gave out. It's shocking that in 2021 a product like this cannot parse a datetime like we could do in any language in 1995.
So my question is: what's the easiest way to parse this datetime correctly in PA/Flow...?
I followed the MS reference:
Workflow definition language functions reference: formatDateTime
And the way to go was with "formatDateTime" function:
formatDateTime('<timestamp>', '<format>'?)
But, before that, the timestamp should be reformated in your case.
My approach will be the following:
Let's assume that the input string will be stored in a variable named timestamp_original.
Take the part before "|" character from the timestamp_original. and remove the Day (at the beginning) from the result.
pass the result to the formatDateTime function.
Use the convertTimeZone function to achieve the TimeZone conversion. (but this part is not working as I expected).
So the final result should be obtained by using the next expressions:
convertTimeZone(formatDateTime(first( split( substring(variables('timestamp_original'), add(2, indexOf(variables('timestamp_original'),','))) , '|' ) )), 'Central Europe Standard Time', 'Greenwich Standard Time')
The solution to the point 3, should be extracting the TimeZone from the timestamp_original string:
trim(first(split(last( split(variables('timestamp_original'), '(' ) ), ')')))
And add some logic to test if this TimeZone contains "UTC+" or "UTC-" and add or extract hours from the obtained timestamp.
I think you can do this.
It should be noted that the variable 'timestamp_original' should be initially in the next format (as the OP mentionned):
Saturday, July 31, 2021 1:35 AM | (UTC+01:00) Dublin, Edinburgh, Lisbon, London
So the result will be: (using the convertTimeZone function)
2021-07-30T23:35:00.0000000
And without using the convertTimeZone function:
2021-07-31T01:35:00.0000000
I hope this has helped. Good luck.
There are several ways to get time in Tarantool:
Using the clock module
Using fiber.time function
Using os.date
But what is the correct way to work with dates?
For the first, there are several routines for Unix epoch:
os.time() — classic Lua time function. Kinda slow and not very efficient. Not recommended to use inside tarantool for getting current epoch, but of course will work. May be used for getting epoch of arbitrary date (within local timezone). ex:
os.time({ year = 2020, month = 6, day = 4 })
will produce 1591261200, which is 12:00:00 in my GMT+3 timezone
clock.time() (and clock.time64()) — High resolution timer, almost raw binding to clock_gettime. More information may be taken from doc
fiber.time() (and also fiber.time64()) — Cached version of clock.time. Updated every event loop iteration. Recommended for use if absolute precision of clock is not required.
For converting epoch into different formats and timezones there are variants:
os.date("<format>" [, epoch ]) — Convert epoch into local timezone.
os.date("!<format>" [, epoch ]) (note ! prefix) — Convert epoch into GMT timezone.
For getting components of a date as a table we may use os.date('*t') for local and os.date('!*t') for UTC
icu-date may be considered it you need to work with different timezones and/or formats.
For example, if you need UTC time, it's ok to use cached fiber.time with os.date:
local fiber = require 'fiber'
os.date("!%Y-%m-%dT%H:%M:%SZ", fiber.time())
will return something like 2020-06-04T11:48:54Z independently on timezone
It depends on your task.
If it's important for you to manipulate with timezones/formats etc.
I suggest to use icu-data library (https://github.com/tarantool/icu-date)
How can I validate date before 1970-01-01 (like 1900-01-01)?
When I try to use CDateVaildator it ends with CTimestamp::getTimestamp() (I found it with help of debugger)
return #mktime($hr,$min,$sec,$mon,$day,$year)
where $hr=0, $min=0, $sec=0, $mon=1, $dat=1, $year=1900 which obviously returns false and this fails whole validation.
CTimestamp::getTimestamp() will generate a timestamp for any dates from 1901 (not 1900!) up to 2038. For dates between 1901 and 1970 it generates a negative number. Just tested it, and the earliest date I can get to work is 14th December 1901. Anything before this throws an error. Not sure how to deal with dates outside this range!
In Yii there is an error described here. The solution is presented there but for some reason it's not included in Yii 1.1.14 although it's marked as committed to trunk.
To make long story short - the fix tries to build timestamp only when there is a property in rules defined.
To use it in own project you have to extend CDateValidator and CDateTimeParser.
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.
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>