What time of day are the periods? For example, if I have 2013-06-02 for "start-date", does that start at the beginning of the day at 00:00? If I have 2014-01-03 for "end-date", does that mean it ends at the end of the day at 23:59?
If this is true, setting "start-date" and "end-date to the same value will mean it will only return data that has happened during that day?
To put in less words, are both the start and end dates inclusive or exclusive?
That's correct. the dates are inclusive. If you set both start-date and end-date to the same value you will get all data for that specific day.
Also worth noting that they respect the time zone you configured in your View Settings.
Related
I'm trying to protect game from abusing time changing. The game save current time and if you enter game soon it check if timeInterval is greater than 0 (if not you can't play). But what about changing timeZone?
If player moved from France to e.g. United Kingdom timeZone changes. Let's say first point was 10:07AM in France and the second in UK after 30 minutes (-1 hour difference). The second point is gonna be 09:37AM? How Date() works when devise TimeZone changes? Do timeInterval() function takes into account that changes? Or it possible to just ignore changing timeZone?
Game should working offline.
Update
How that works
The Date() is saved at the very first entry in app. (In CoreData)
The next time the app enters, it will check the new and old dates. Using TimeInterval()
Case1 - result is greater than 0. It means the entry in "Future". Entry allows. Save the new Date instead of the old.
Case2 - result is less than 0. It means the entry in "Past". That impossible without date changing. Entry is prohibited until the new date is greater than old.
From the Date() documentation:
A Date value encapsulate a single point in time, independent of any particular calendrical system or time zone.
I would therefore expect this to be a non-issue - the first point in time would still be 30 minutes before the second point in time, and I'd expect that to be respected by timeInterval. I'd expect the same Date() to be returned by now at a given point in time, regardless of the time zone of the system running the code.
Is there a standard for encoding a date as a timestamp? My thoughts:
This should be 12:00pm UTC in local time, eg 9:00am at T-3, therefore anyone consuming the timestamp, regardless of their -12/+12 offset, will recognize the same date, regardless of whether they parse at the UTC timezone
It could be 12:00pm at UTC
It could be the start of the day (12:00am) at UTC
It could be start of the day (12:00am UTC) in local time eg 9:00pm at T-3
Is there an official spec or standard to adhere to?
It would be easy to point to this document and say 'this is the standard' as opposed to being unaware and having to change our logic down the line.
There isn't a standard for this, because a date and a timestamp are logically two very different concepts.
A date covers the entire range of time on that day, not a specific point in time.
It may be a different date for a person in another time zone at any given point in time, but dates themselves do not have any association with time zones. Visualize a date as just a square on a calendar, not a point on a timeline.
Many APIs will use midnight (00:00) as the default time when a date-only value is assigned to a date+time value. However:
Whether it is UTC based or local-time based is very dependent on that particular API. There is no standard for this, nor is one answer necessarily better than the other.
Assigning a local-time midnight can be problematic for time zones with transitions near midnight. For example, in Santiago, Chile on 2019-09-08, the day started at 01:00 due to the start of DST. There was no 00:00 on that day.
Also, you tagged your question with momentjs. Since a Moment object is basically a timestamp (not a date), then Moment.js will generally assign the start of the day if provided a date-only value. The time zone involved is key to deciding which moment that actually is, which illustrates my prior points.
For example:
// Parsing as UTC
moment.utc('2019-09-08').format() //=> "2019-09-08T00:00:00Z"
// Parsing as Local Time (my local time zone is US Pacific Time)
moment('2019-09-08').format() //=> "2019-09-08T00:00:00-07:00"
// Parsing in a specific time zone (on a day without midnight)
moment.tz('2019-09-08', 'America/Santiago').format() //=> "2019-09-08T01:00:00-03:00"
Also keep in mind that sometimes APIs can be misnamed. The JavaScript Date object is not a date-only value, but actually a timestamp, just like a moment.
Here I'm saving the date range using golang. Suppose we have to save the all monday comes between the range of the 1-may-2018 to 14-july-2018.
How we will find all the monday between these range using golang and on the other hand we have set the start_time (8:00 A.M.) and the end_time (6:00 P.M.) of the first two coming monday in the database but on the third monday we have a change in the schedule that there is a time change like start_time (9:00 A.M.) and end_time (5:00 P.M.). Then how I will make my database to make this situation in practically using the golang.
Can Anybody help me for this to solve this solution. I made a database for and I do ppr work on it and make some fields shown below:-
Fields for Schedule //Schedule is a collection name
Id (int)
Day (string)
Start_hours (int)
Start_minutes (int)
End_hours (int)
End_minutes (int)
Start_date (timestamp)
End_date (timestamp)
How I will select monday between the selected range and how will I do the situation I explained above can anybody give guidance to me to make this situation easier. Thank you if this is a basic question then I'm really sorry.
I'd make something like this.
Find the first Monday date from the date range (see for example How do I get the first Monday of a given month in Go?
Mondays happen every week, so you can easily find the rest of dates by adding 7 days till the end date
Store all the Monday dates you found with the start and end times
I wouldn't bother with hours and minutes as you can easily get them from the timestamps in Go. Here is the simplified DB structure I would make
Fields for Schedule //Schedule is a collection name
Id (int)
Day (string)
Date (timestamp) // the actual date
Start (timestamp)
End (timestamp)
You don't need any more fields. You can get the day of the week (Day (string) in your structure, e.g. Monday) from the Date field too, but I believe if you want to query the collection by different days, this might speed things up, but be careful if you need to adjust for time zones. If you work with more than one, then store everything in UTC and you may have an extra filed Timezone, cos a date could be Monday for one zone and Sunday for another.
So, the Schedule will hold weekdays and start and end times for each of them. I'm not sure if you need to store initial date ranges, the Schedule collection will hold that range as well, form the first record to the last one. In my mind, I'd initially populate the collection with a given date range, then later on, I can modify it by adding new days, or deleting them.
When you query this collection with some start and end date range for the Date field, if your first result comes newer than 7 days from the start, this means you miss 1 or more entries from the start. If the last result comes older than 7 days from the range end, this means you miss some entries prior to the range end.
There is nothing specific to Go, in my opinion, Go works well with dates and you don't need any special date structures in your DB.
How do I get date function to return date according to current system date?
Right now, with the code snippet below, it always returns UK time, not the current system date.
<calculate>
<script>$ = concat( num2date(date(), DateFmt()), " ", num2Time(Time(), TimeFmt()) )</script>
Any help is appreciated!
It's probably not UK time exactly, but rather GMT (or UTC, to use a more precise term). The UK happens to be aligned to GMT in the winter, but in the summer it advances one hour to BST for daylight saving time.
Now, I've never used LiveCycle myself, but nonetheless, I've read through the somewhat minimal docs for LiveCycle FormCalc Date and Time Functions, and the spec, and it appears to me that a few critical mistakes were made.
The date and time functions return UTC-based values, but only the time-related functions have been made aware of the local time zone. That is, there are separate Num2Time and Num2GMTime functions, but there is only one Num2Date function.
The Num2Date function works in terms of whole integer days, and thus they are simply days since 1900-01-01. Therefore, the number being passed in to the function must already be representative of the desired time zone. However, the Date function only gets the current GMT date. There does not appear to be a function to get the current local date.
It's different on the time side, because of the millisecond precision involved. However, there's yet another flaw here. Despite the docs saying that the Time function returning "the number of milliseconds since the epoch", its actually returning only the number of milliseconds since midnight GMT. There is no day-over-day accumulation of milliseconds from the date part. The docs here are even lying in their sample code which says:
Returns the current system time as the number of milliseconds since the epoch.
Time() => 71533235 at precisely 3:52:15 P.M. on September 15th, 2003 to a user in the Eastern Standard Time (EST) zone.
If that was indeed the case (and ensuring to use their 1900-01-01 epoch), the value would actually include an additional 3272572800000 milliseconds representing the days between 1900-01-01 and 2003-09-15, bringing the total timestamp to 3272644333235. Additionally, there's a typo there, because the timestamp they give is 3:52:13, not 3:52:15. Clearly nobody paid close attention to these docs!
The real problem is that one cannot be certain that the number of milliseconds since midnight of the current day in the local time zone is the same on every day. If instead of getting the current time, you were working with past stored time values, you might be an hour off (+ or -) if the current offset is different due to daylight saving time. Example: Eastern time might be UTC-5 or UTC-4, but only the offset currently in effect will be used by the Num2Time function, even if the date you're working with is using the other offset.
So, in summary, the Date function is insufficient, leading to your observations, and the date/time functionality in general is poorly designed. Given the constraints of this API, I can't even recommend a workaround. There would have to be a LocalDate function of some kind to be used instead of the Date function, but it doesn't exist.
The only advice I can offer is that it appears (from my research, not experience) that LiveCycle can use either FormCalc or JavaScript. So - use JavaScript instead.
I have a variable called sentDate which stores the month and day from Nov 27th - Dec 6th.Each day has a number of sentiment ratings that it represents therefore I need to assign unique day codes to each day so I can perform...
allSents(dayCodes==1)
So far I have managed to assign day codes using...
[a,b,dayCodes]=unique(sentDate);
[d,e,allSents]=unique(sentiment);
However the day codes take the last digit on the date e.g 27th becomes 7, 28th becomes 8, etc. I need it so the day codes start from 1 and increase for each day until the 6th of December, therefore 1-11.
Any idea on how I may do this ?
have you tried the datenum function? then subtract off whatever offset to give the appropriate start day number.
For those who may have a similar problem, by specifying stable in as a parameter e.g
[a,b,dayCodes]=unique(sentDate,'stable');
Will specify the daycodes in the same order as in sentDate.