I have the following data which i was querying with .net time and ran into issues with timezones and spans. I was recommended to use Noda Time.
"MarketStates": {
"dataTimeZone": "America/New_York",
"monday": [
{
"start": "04:00:00",
"end": "09:30:00",
"state": "premarket"
},
{
"start": "09:30:00",
"end": "16:00:00",
"state": "market"
}
],
"holidays": [
"1/1/1998",
"1/1/1999",
"1/1/2001"
],
"earlyCloses": {
"7/3/2000": "13:00:00",
"7/3/2001": "13:00:00"
}
}
I am writing a function IsMarketOpen providing a time to test against, and the above MarketStates json database - it returns true if the current time is during market open and false if a holiday or earlyClose.
For the market states (monday above) I will use a LocalTime.
For the earlyCloses I plan to use ZonedDateTime.
For the passed time into this method, I will use a ZonedDateTime.
For holidays would I need to keep the timezone? I cannot find a ZonedDate, only OffsetDate or LocalDate?
In summary, should I keep everything ZonedDateTime (since i have the time zone specified in the json database snippet above), or use a LocalDateTime and then perform the conversion/testing at that point?
Please bear with me for the above question I didn't realize that time is actually so hard and need guidance for structure selection, I will adapt as per comments if extra context is needed. Thank you.
Your earlyCloses looks like it's really a Dictionary<LocalDate, LocalTime>, and holidays is a List<LocalDate>. (As a side note, it's pretty awful that it's not using ISO-8601 for the date format... I can't tell whether those early closes are July 3rd or March 7th.)
The time zone is specified by dataTimeZone, but I'd suggest keeping it as a string in the model, and converting it to a DateTimeZone when you need to.
The thrust of what I'm saying is that I'd encourage you to make the values in your direct model (loaded from JSON and saved to JSON) match what's actually stored in the JSON. You could have a wrapper around that model which (for example) converted the early closes into ZonedDateTime values... but I've generally found it really useful to keep the "plain model" simple, so you can immediately guess the representation in the JSON just from looking at it.
Related
My model will optionally take a time in many utterances.
So examples...
add wet diaper. <-------- assumes current time
add wet diaper at 4:00 PM
add bottle at noon
What would be the best way to model 4 PM/AM so that in my actions I can collect the time?
You'll want to define an action that accepts an optional input, and make sure the type is 'DateTimeExpression'. In your NL training, you can say things like 'do this thing at 4PM' or 'do this thing'. Both are valid because you made the date optional. In your javascript, check to see if the user said a date. If they did, use it. If not, you can default to now. Refer to this link for grabbing the time from javascript. The date api will parse dates to the device's local time by default (can be overridden).
In your action
input (searchDate) {
type (time.DateTimeExpression)
min(Optional) max (One)
}
In your javascript
var currentTime = dates.ZonedDateTime.now().getDateTime();
if (searchDate)
currentTime = //Grab the date from searchDate.
Use this for reference.
There is no primitive type DateTime, but there is a viv.time library you can use, and in fact there is viv.time.DateTimeExpression concept you can use.
viv.time.DateTimeExpression not only handles "4 AM" but also "tomorrow 4 AM", you can read more here. I would say it is one of the most commonly used library concepts.
I am using REST API endpoint https://outlook.office.com/api/v1.0/me/events/ to create meeting in Outlook live. The payload of meeting looks like-
{
"Subject":"Test Meeting",
"Location":{
"DisplayName":""
},
"Start":"2017-03-02T18:00:00Z",
"End":"2017-03-02T19:00:00Z",
"Body":{
"ContentType":"HTML",
"Content":"<html><body>Test Meeting Content<\/body><\/html>"
},
"Recurrence":{
"Pattern":{
"Type":"Weekly",
"Interval":1,
"Month":0,
"Index":"First",
"FirstDayOfWeek":"Sunday",
"DayOfMonth":0,
"DaysOfWeek":["Thursday"]
},
"Range":{
"Type":"EndDate",
"StartDate":"2017-03-02",
"EndDate":"2017-03-31"
}},
"Attendees":[
{
"EmailAddress":{
"Address":"starstart#example.com"
},
"Type":"Required"
}
]
}
For this weekly recurring event for a month, first two occurrence are getting created at right time but the rest of three meeting events are getting created with an hour delay (instead of 10:00AM UTC, it is 11:00AM UTC).
I even tried with v2.0 endpoint with no luck. I also tried passing timezone for meeting start date and end date, but it is showing same behavior.
Did anyone hit this or similar issue? Any pointers would be of great help, thank you!
Reference to API- https://msdn.microsoft.com/office/office365/APi/calendar-rest-operations#CreateEvents
The API is technically behaving correctly here. UTC doesn't change, but the timezone you have configured on your client likely does. In the US Daylight Savings start on March 12, so you see that the appointment "shifts" in the local view so that the appointment always starts at 18:00 UTC, as you specified :)
So my guess is that you want the start time to stay constant across the DST change, so what you really want to do here is specify the timezone for the user in the request. I'd recommend using the v2 API, where the Start and End change types to a DateTimeTimeZone, allowing you to specify the TZ by name:
"Start": {
"DateTime": "2017-03-02T10:00:00",
"TimeZone": "Pacific Standard Time"
},
"End": {
"DateTime": "2017-03-02T11:00:00",
"TimeZone": "Pacific Standard Time"
},
However, if you need to stay with the v1 API, then you can still specify the TZ in the request, using the StartTimeZone and EndTimeZone properties. The additional work you have to do here is calculate the offsets in the Start and End values. So for example, for Pacific Standard Time, the offset is -08:00 from UTC, so the relevant bit would look like:
"Start": "2017-03-02T10:00:00-08:00",
"StartTimeZone": "Pacific Standard Time",
"End": "2017-03-02T11:00:00-08:00",
"EndTimeZone": "Pacific Standard Time",
We have a system where citizens download Questionnaire from a server, fill it in and submit a QuestionnaireResponse back into the server, storing it there. In our case, these are simple questions about how you're feeling and symptoms. A health worker can then access the QuestionnaireResponse. The health workers don't want the answers, but a score which has been calculated based on the answers.
Some vendors (non-FHIR) allow creating a form and a scoring system at the same time. If we wanted to support this within FHIR, I'm assuming we would have to embed the scoring information inside the Questionnaire (or potentially a separate resource, but that would give some redundance perhaps).
Is this best solved with extensions to the Questionnaire-resource, another resource or some other mechanism? And what'd be the best way (architectureally) to implement the actual scoring. Would it best be a separate application which subscribes to the QuestionnaireResponses, downloads the Questionnaire, extracts the scoring system, evaluates and then writes the score back into the QuestionnareResponse?
Are there other standards we should be looking to for help on this?
And for those especially interested, here's a really simplified Questionnaire resource. Typically it'd have more questions of course. Right now we've put the score into the 'code', which doesn't seem like a good idea.
{
"resourceType":"Questionnaire",
"id":"1140",
"meta":{
"versionId":"11",
"lastUpdated":"2016-06-14T13:01:47.000+00:00"
},
"text":{
"status":"generated",
"div":"<div><!-- Snipped for Brevity --></div>"
},
"status":"published",
"date":"2016",
"group":{
"linkId":"group1",
"title":"HelsaMi Hjertesvikt",
"concept":[
{
"system":"unknown",
"code":"unknown",
"display":"Hjertesvikt"
}
],
"group":[
{
"linkId":"group2",
"question":[
{
"linkId":"Feeling",
"text":"How do you feel today?",
"type":"choice",
"option":[
{
"system":"unknown",
"code":"3",
"display":"Good"
},
{
"system":"unknown",
"code":"2",
"display":"Medium"
},
{
"system":"unknown",
"code":"1",
"display":"Bad"
}
]
}
]
}
]
}
}
Would an extension for example look like this (embedded in to each option):
"extension": [{
"url": "http://example.com/scoring",
"valueInteger": 10
}
]
The score would simply be another answer to a "special" question. The question would have an extension that defines how the score is calculated. The question would likely be "read only" and could be hidden. You could even have multiple such questions, for example one per section to provide a sub-calculation and then one for the overall questionnare to total it up. As well, look at the coded ordinal extension for the Coding data type as it may be helpful for capturing scores for individual question answers.
I'm working with SailsJS and MongoDB and I have an API that has two models and I want to store Date and Time separately but as in the official documentation said it doesn't have a typeof Time attribute, just Date and DateTime. So, I'm using DateTime to store Time values.
I send the values in the request to be stored in the database, I have no problem to store dates, I just send a value like:
2015-12-16
and that's it, it is stored in the table with no problem, but when I want to store a Time value like:
19:23:12
it doesn't works. The error is:
{
"error": "E_VALIDATION",
"status": 400,
"summary": "1 attribute is invalid",
"model": "ReTime",
"invalidAttributes": {
"value": [
{
"rule": "datetime",
"message": "`undefined` should be a datetime (instead of \"19:23:12\", which is a string)"
}
]
}
}
So, any idea how to send the time value to be stored in a DateTime attribute?
I also have tried to send it in different formats like:
0000-00-00T19:23:12.000Z
0000-00-00T19:23:12
T19:23:12.000Z
19:23:12.000Z
19:23:12
But any of them works fine.
Also I was thinking to store both values (Date and Time) in plain text, I mean typeof String attributes. But I need to make some queries and I don't know if it will affect the performance with the waterline ORM.
Please any kind of help will come in handy.
Thanks a lot!
You have two options here. The best would be to simply store the date and time as a datetime and parse them into separate values when you need to use them. MongoDB will store this in BSON format and this will be the most efficient method.
Otherwise, you could use string and create a custom validation rule as described in the Sails documentation.
After editing a document in GoogleDrive, it seems that the LastModified value doesn't change immediately sometimes. It looks like the value will be updated in a few minutes.
I tried to fetch the Etag of the document by DriveSDK, it also happens to the Etag value.
This strange behavior stops me getting the document status (modified or not) at real time. Any suggestions will be highly appreciated.
[Sample Request and Response]
The request is just GoogleDrive ListFiles : https://www.googleapis.com/drive/v2/files
Here's the part of the response JSON, and you can see that the ModifiedDate is earlier than ModifiedByMeDate.
{
"kind": "drive#fileList",
"etag": "\"3NNCnvnQuji-pODa6SMQ6atlc3M/oKnf21kAcJKTCIycS597xCSR2bk\"",
"selfLink": "https://www.googleapis.com/drive/v2/files",
"items": [
{
"kind": "drive#file",
"id": "1lZjcJIf3Chuu5upFqtiqfTRnRw7*****rFL_tlO8A",
"etag": "\"3NNCnvnQuji-pODa6SMQ6atlc3M/MTM1NDY5MzMyMzQ1Mg\"",
"selfLink": "https://www.googleapis.com/drive/v2/files/1lZjcJIf3Chuu5upFqtiqfTRnRw7wSUjbRurFL_tlO8A",
"alternateLink": "https://docs.google.com/a/*****.com/document/d/1lZjcJIf3Chuu5upFqtiqfTRnRw7wSUjbRurFL_tlO8A/edit",
"embedLink": "https://docs.google.com/a/*****.com/document/d/1lZjcJIf3Chuu5upFqtiqfTRnRw7wSUjbRurFL_tlO8A/preview",
"iconLink": "https://ssl.gstatic.com/docs/doclist/images/icon_11_document_list.png",
"thumbnailLink": "https://docs.google.com/feeds/vt?gd=true&id=1lZjcJIf3Chuu5upFqtiq*****7wSUjbRurFL_tlO8A&v=22&s=AMedNnoAAAAAU*****UK74n3UiIg0L4TY-NwP3EaAU&sz=s220",
"title": "TestFile",
"mimeType": "application/vnd.google-apps.document",
"labels": {
"starred": false,
"hidden": false,
"trashed": false,
"restricted": false,
"viewed": true
},
"createdDate": "2012-07-24T08:14:13.918Z",
"modifiedDate": "2012-12-06T01:49:57.982Z",
"modifiedByMeDate": "2012-12-06T01:49:57.982Z",
"lastViewedByMeDate": "2012-12-06T01:50:06.974Z",
"parents": [
{
"kind": "drive#parentReference",
"id": "0AJ-aGTt-gWksUk9PVA",
"selfLink": "https://www.googleapis.com/drive/v2/files/1lZjcJIf3Chuu5upFqtiqfTRnRw7wSUjbRurFL_tlO8A/parents/0AJ-aGTt-gWksUk9PVA",
"parentLink": "https://www.googleapis.com/drive/v2/files/0AJ-aGTt-gWksUk9PVA",
"isRoot": true
}
],
"exportLinks": {
"application/vnd.openxmlformats-officedocument.wordprocessingml.document": "https://docs.google.com/feeds/download/documents/export/Export?id=1l*****huu5upFqtiqfTRnRw7wSUjbRurFL_tlO8A&exportFormat=docx",
"application/vnd.oasis.opendocument.text": "https://docs.google.com/feeds/download/documents/export/Export?id=1lZjcJIf3Chuu5upF*****SUjbRurFL_tlO8A&exportFormat=odt",
"text/html": "https://docs.google.com/feeds/download/documents/export/Export?id=1lZjcJIf3Chuu5upFqtiqfTRnRw7wSUj*****L_tlO8A&exportFormat=html",
"application/rtf": "https://docs.google.com/feeds/download/documents/export/Export?id=1lZjcJIf3Chuu5upFqtiq*****SUjbRurFL_tlO8A&exportFormat=rtf",
"text/plain": "https://docs.google.com/feeds/download/documents/export/Export?id=1lZjcJIf3Chuu5upFqtiqf*****SUjbRurFL_tlO8A&exportFormat=txt",
"application/pdf": "https://docs.google.com/feeds/download/documents/export/Export?id=1lZjcJIf3C*****fTRnRw7wSUjbRurFL_tlO8A&exportFormat=pdf"
},
"userPermission": {
"kind": "drive#permission",
"etag": "\"3NNCnvnQuji-pODa6SMQ6atlc3M/6LfqbkrWujmUe1WSDkyhTxdIUCc\"",
"id": "me",
"selfLink": "https://www.googleapis.com/drive/v2/files/1lZjcJIf3Chuu5upFqtiqfTRnRw7wSUjbRurFL_tlO8A/permissions/me",
"role": "owner",
"type": "user"
},
"quotaBytesUsed": "0",
"ownerNames": [
"***** *****"
],
"lastModifyingUserName": "***** *****",
"editable": true,
"writersCanShare": true,
"appDataContents": false
},
This doesn't answer the question but I would just like to comment on what etag and modifiedDate means on File resources. File etag seems to just directly correspond to the modifiedDate value. The second part of the etag (after the slash) is just an encoding of the modifiedDate.
In the Documents List API, there's a property called app:edited besides the updated property (which seems to correspond to modifiedDate here). The way these timestamps change are not clearly documented, but I've noticed that app:edited changes on virtually every change (e.g. starring of a file, even by another user if I remember correctly) and updated changes are more limited (e.g. for content modifications and permission changes). And the etag before directly corresponds to app:edited, which is good because a change of app:edited indicates that there was really a change (sometimes it changes too much though, like starring of a file by a different user, as it doesn't really affect the current user's metadata).
What I want to say is that I think Documents List's etag (and having the app:edited property) is better than the Drive API having modifiedDate only. The problem with the latter is that you don't have a reliable way to determine if a File resource has changed or not. For example, if you just like to check if a File resource has changed, you could've used the files.get method with an If-None-Match header using the etag. But etag doesn't always change because modifiedDate doesn't always change. It changes, for example, when there's new content, or changed ACL, or changed description, but does not change, for example, when trashed, or parents changed. When comparing two resources, you can't reliably determine which one is newer. Add the fact that modifiedDate can be set (e.g. it would be possible to set the modifiedDate to an earlier value, or even a constant value, and the etag with it). The intended purpose of etag is lost. There are many cases where we can't just rely on the changes list, and if etag behaves properly, it would be huge help for determining the changes that happened.
What I suggest is to restore the behavior of etag to be similar to the Documents List API. And to help in determining which resource has newer information, add back the app:edited property as well (I think just documenting the value of etag is enough, like officially saying that the second part is an encoding of a timestamp, so that we can rely on it to be always increasing). Also, I think it's better to just change the modifiedDate property on content modification, and nothing else (e.g. not with ACL changes or description changes).
Similarly, etag of Revision(List) resources of verbatim files is not very useful as well. Since the downloadUrl property changes regularly, the etags of each Revision and the whole list changes with it, rendering it useless (because you can't use it to check if the revisions didn't change). Good thing there is the md5Checksum property you can compare, but it's not reliable in some cases.
Google's infrastructure updates Google docs asynchronously after updates. To my knowledge, this affects etag, thumbnails, and probably md5sum and certain modified dates.
Some documentation from Google confirming which items are asynchronous and which are synchronous would be tremendously useful to developers.
The etag is in effect, and often in practice, a hash of the file's metadata. If you change anything about a regular file (not a Doc or Sheet, see below), or just "touch" it using eg
https://www.googleapis.com/drive/v2/files/blah_my_file_id/touch
the metadata is changed, and the etag you get back in the response WILL be different. My application, and likely thousands of others, utterly depend on this behavior.
If you're seeing different, it's somewhere in your setup. Where the OP said "you can see that the ModifiedDate is earlier than ModifiedByMeDate"... er, it's not. It's identical in the JSON response they provided. The "LastViewedByMeDate" is different.
Google Docs, Sheets etc, are a completely different system since they are collaborative. Collaborative systems keep individual changes, and need very complex logic to keep it all straight; they're not just regular files. What's "in" your Drive is just a shortcut to processes running somewhere else in Google's caves, and the metadata you read from Drive may well be out of sync with recent changes. Google's now withdrawn collaborative Realtime API (which may still drive Docs and Sheets, I don't know) provided a serverRevision property which was the reliable way to track if any changes had occurred.