I'm creating a customized function that does some calculations for a given time.
When a time is entered in a cell, for example 4:00 PM, this is automatically converted into a date, in this case 12/30/1899 16:00:00 and when the function getTheMinutes() is called, it returns 2 instead of 0.
function getTheMinutes(dateTime){
return dateTime.getMinutes();
}
The behavior of the function is different if it's used for a most recent date like 5/1/2019 16:00:00.
I want the user to be able to just write a time in a cell then use the customized function in another cell. Please let me know your thoughts.
Now that you have indicated the time zone for your spreadsheet I can confirm what #RobG deduced almost a day ago, which is that Guatemala adjusted its difference relative to UTC. Something you have confirmed is treated as by two minutes with effect from October 5, 1918.
More specifically, the adjustment was of 2 minutes and 4 seconds and effective from 03:00 that day:
(Source IANA Version 2019b file northamerica.)
There have been very many such minor adjustments around the world over the years (even between towns in the same country) and adjustments continue, though usually of a whole hour – between 'standard' and Summer time. Sheets has very properly recognised that "normal arithmetic" 'does not work' across such a transition and while noon yesterday to noon today for example is normally, for any one specific location, a difference of 24 hours it is often 23 hours or 25 hours on the day that clocks go forward/back.
And the moral of the story is to beware of obliging Sheets to assume, for want of a specific date, that is has the index number 0 - i.e. is December 30, 1899.
I made some testing, and I found out that the formula is giving a wrong result any minute before 10/5/1918 0:03:00, from that DateTime on, the formula is working as expected.
Here is my sheet https://docs.google.com/spreadsheets/d/1psm8_GJYRczO53TILJCOzo0p4GpnS-ooiGWqOJrC8ZU/edit?usp=sharing
I would need to do a date validation in my customized formula to make it useful. I don't know why google sheets is choosing that date as default when just a time is typed in a cell, I think it should be improved.
Related
I am working with overnight data (in particular I am concerned about the hours 6PM-6AM). I want this time frame to count as “day 1” for my study. My problem is that the date changes at midnight. Can anyone recommend code to reassign the time-frames that I am concerned about as “day1, day 2, etc.” instead of the Julian date. I am new to this so any suggestions would be very much appreciated!
*Update, here is a screenshot of the data I am working with. So, the column on the left is the julian date.. in this example I am looking at day 305 and 306 and the hours 18:20 (305) to 6:20 (306). I want these hours to be classified as day 1, instead of the date changing at midnight. Also, I need to get rid of the random date that is attached to my time column. I'm sure there is an easy way to do that, but if anyone knows off the top of your head I'd appreciate that!
Again, I'm very new to R and coding language, please be gentle!
Thanks a million.
You didn't mention what language you're using.
Given timespans 6pm to 6am, I believe the simplest solution would be to decrement 7 hours from any given date - then all of your timestamps would have the start day of the timespan as their day component.
I am currently using a budget sheet that automatically updates date cells to the next "payment" date for a bill. As an example:
=VALUE("2019-03-08")+14*FLOOR((NOW()-VALUE("2019-03-08"))/14)
The cell starts with a date and it then updates every 14 days to the new date. This shows me a cell that has the date of the biweekly payment that is due. In the above example, the cell shows the value of "2019-03-08" until 2 weeks have passed. Once 14 days have passed, the cell will automatically upload to "2019-03-22". This automation will continue forever in 14-day increments. The date displayed in the cell will always update automatically to the next 14-day date. This helps me display the exact due date of a biweekly payment without updating the cell.
I want to do the same thing for a monthly payment, but using a day count of 30 is not very accurate. Is there a way to modify this method to let me update the date automatically to the 24th of the month, every month, on that day. So I start with 2/24/2019 and when 3/24/2019 hits, the cell updates to that date, and so on. The reason this is not accurate is that the months are not all 30 day periods. February is 28 days and some are 31 days. I want the cell to increment in 1 month periods in the same way that the above formula updates in 14-day increments. As an example: The date will display "2/24/2019" until the same day on the next month occurs, then the cell will update to "3/24/2019". This process will continue forever with 4/24/2019, 5/24/2019, etc. It will continue with the year as well, so 12/24/2019 will change automatically to 01/24/2020.
UPDATE: Updated the description with examples of how the behavior works and what I am looking for...
It's much simpler than this. Use the EDATE function (e.g.):
=EDATE(A1,1)
Where A1 is your starting date and 1 is the number of months you which to increment by. See https://support.google.com/docs/answer/3092974?hl=en for more details.
this formula will increase the month every 24th and accounts for year change as well
=IF(DAY(TODAY())>=24,
DATE(YEAR(TODAY()), MONTH(TODAY())+1, 24),
DATE(YEAR(TODAY()), MONTH(TODAY()), 24))
paste where you need and drag down:
=VALUE("2019-"&ROW(A3)&"-08")+14*FLOOR((NOW()-VALUE("2019-"&ROW(A3)&"-08"))/14)
I have a quick question regarding handling of dates and times in 800xA.
What I´m trying to do is to take the current date, add/subtract days and save the result to a new variable.
I´m currently using "Date_and_timetocalendarstruct", to split the current date down to "current year", "current month", "current week" and so on.
I want to work it like this :
for example : take the current date and subtract it by one (or any other number) and thus, generating a new date to store away for future use.
This particular scenario is in ABB,s 800xA systems and its configured against a AC 800M controller.
I have tried a couple of things so for, regarding applying arithmetic operations to dates, but without success.
I hope someone here could point me in the right direction.
Thanks in advance
I think what you missed is the time data type.
date_and_time is used for a Calendar type of Data while time is a time span, e.g. a number of days.
What I understand you want to calculate is (in ST, but works in FBD as well):
OutDate := sub( InDate, Days);
Where OutDate and InDate are of Type date_and_time and Days is time.
If you specify Days with Value 5d, you will get OutDate as 5 days before InDate.
In a similar way, you will get a time span (type time) as output when subtracting two date_and_time values!
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.
Is there a function in Haskell that will allow me to enter component of a date (like a string representation or day month year components) that I can get information from (like day of week, days in a month, etc.)?
I've looked online and it looks like there are a lot of custom libraries, but I'm hoping there's one in the standard prelude library of ghci 10.6.4 that's just not well documented?
Are Data.Time.Calendar and Data.Time.Format in the time library sufficient?
You can parse a string representation of a date and get the length of a month using gregorianMonthLength. Not sure about day of the week, though you could format the date as a string using a format that just displays the week day.
A quick Google search turns up this, which may be what you want. It lets you parse strings representing dates and extract information from them.
You can find the day of the week with mondayStartWeek or sundayStartWeek, depending on whether you think a week starts on Monday, or on Sunday. Both functions are in Data.Time.Calendar.OrdinalDate.
λ> snd $ mondayStartWeek $ fromGregorian 2017 10 3
2
In the above example, the return value is 2, which indicates the second day of the week. Since the function is called mondayStartWeek, Monday is the first day, so 2 corresponds to Tuesday. This is true of October 3, 2017.
A warning regarding week numbers
Both functions return a tuple, where the second element is the week day. As far as I can tell, that should be trustworthy.
The first element, however, is the week number of the year. Be careful with that, because the rules for week numbering are political. If I remember correctly, in USA, week 1 is the week that contains January 1. That's not the case in Denmark, where I live. Here, week 1 is the first week where Thursday falls in the new year. This can mean that December 31 can fall in week 1 of the next year. IIRC, this is the rule for many other European countries. Some years, the American and the European week numbers align, but some years, they don't.