I see there is a function to set the time to an arbitrary ISO8601 time (now my roku seems to think its January!), but what I need is to get today’s date and time in iso8601 format as a string… and also an arbitrary date in the past…
- Joel
You’ll need to build it yourself. There is no built in method.
I don’t think there’s a function, but it should be trivial to write your own. Once you have that you you can set an roDateTime object to an arbitrary timestamp and then use your function to get the ISO formatted string. By the way, there’s no way to set the time/date of the box itself, just the time/date of an roDateTime object.
-JT
Yeah, trivial to you!
Actually, seems to me that date calculations are insanely complex - for instance, how do you know what the day and month is for an arbitrary today minus x days? You have to calculate leap years, months with 30 days instead of 31 and February which is shorter every four years, plus years are adjusted due to variations in the earths orbit by NIST,aren’t they?
Yeah, I can’t figure it out. if I have 2010-10-19 - X number of days how do I come up with the exact year month and day? Seems like it would need lots of lookup tables and such to be able to handle this even for a short time range, and unless I’m misunderstandin roDAteTime, it doesn’t do that… or does it?
What does “Initialize the date/time value using the number of seconds from epoch” mean in english?
Essentially, I need to pass in two dates to get back the data I need - today, and today - X formatted as “YYYY-MM-DD HH:MM:SS” so I really have to be able to give the correct info, and I’m not seeing how to do this at all.
- Joel
nowDate = CreateObject("roDateTime")
nowDate.Mark()
calcDateSeconds = nowDate.AsSeconds() - (numDays * 60 *60 * 24) 'number of days * seconds in minute * minutes in hour * hours in day
calcDate = CreateObject("roDateTime")
calcDate.FromSeconds(calcDateSeconds)
calcDate.ToLocalTime()
“jbrave” wrote:
What does “Initialize the date/time value using the number of seconds from epoch” mean in english?
The Unix epoch was the beginning of the day on January 1, 1970 UTC or 1970-01-01T00:00:00Z ISO 8601. So, 1:00am on 1/1/1970 would have a Unix timestamp of 3600. Right now it’s 1287574264 seconds since the epoch. 1287574264/3600/24 gives 14902.5 days since the epoch. All calculations using the built-in functions should handle things like leap years, but I doubt they account for leap seconds. There’s a long discussion of Unix time and leap seconds here if you’re interested.
-JT
“TheEndless” wrote:
nowDate = CreateObject("roDateTime") nowDate.Mark() calcDateSeconds = nowDate.AsSeconds() - (numDays * 60 *60 * 24) 'number of days * seconds in minute * minutes in hour * hours in day calcDate = CreateObject("roDateTime") calcDate.FromSeconds(calcDateSeconds) calcDate.ToLocalTime()
Just a note that this of course doesn’t handle daylight savings time changes and suchlike, which means you can only trust it to get the right date, not time – and then only far enough away from midnight – but correct time for the “date in the past” may not be an actual requirement.
Truly correct handling of time requires a LOT of code and data. Most likely more than we want to carry around in a channel package …
“GandK-Geoff” wrote:
“TheEndless” wrote:
nowDate = CreateObject("roDateTime") nowDate.Mark() calcDateSeconds = nowDate.AsSeconds() - (numDays * 60 *60 * 24) 'number of days * seconds in minute * minutes in hour * hours in day calcDate = CreateObject("roDateTime") calcDate.FromSeconds(calcDateSeconds) calcDate.ToLocalTime()Just a note that this of course doesn’t handle daylight savings time changes and suchlike, which means you can only trust it to get the right date, not time – and then only far enough away from midnight – but correct time for the “date in the past” may not be an actual requirement.
Truly correct handling of time requires a LOT of code and data. Most likely more than we want to carry around in a channel package …
It’d be nice if someone like NIST would provide an api or protocol to definitively handle these kinds of calculations. So for example:
“http://server/calc?StartDate=20091020220101GMT-5&EndDate=20101021090323GMT-5&format=xml”
would return some xml with the properly calculated interval between the two dates. Or something along those lines. I’ve had to deal with date calculations before, and I agree they get hairy fast. I looked around for somebody providing something like this before posting: I thought for sure someone like Google, NIST, Yahoo, or MS would already be providing this service, but apparently not. There are lots of sites that will do the calcuations in javascript or another language and just display it back to you, but then you’d have to scrape the results if you wanted to use them in a Roku channel.
“GandK-Geoff” wrote:
Just a note that this of course doesn’t handle daylight savings time changes and suchlike, which means you can only trust it to get the right date, not time – and then only far enough away from midnight – but correct time for the “date in the past” may not be an actual requirement.Truly correct handling of time requires a LOT of code and data. Most likely more than we want to carry around in a channel package …
The roDateTime object assumes GMT. I would expect the .ToLocalTime() (last line of my sample code) to take care of the DST calculation, so you’d want to make sure the initial date is GMT prior to the calculation, but my assumption was that he just needed to do date and not time, based on his “arbitrary today minus x days” question.
“TheEndless” wrote:
you’d want to make sure the initial date is GMT prior to the calculation
Right, but that may not be easy to manage in all circumstances. Still, I admit that in thinking immediately of the general case (I’ve had to do a lot of finicky time math in my day), I forgot that there was a useful subset of the problem space that actually could be decently handled.
“TheEndless” wrote:
but my assumption was that he just needed to do date and not time, based on his “arbitrary today minus x days” question.
Sure. I guessed the same, but I wanted to bring it up in case my interpretation was wrong and he really did care about (past) times – because let me tell you, there’s nothing like that sinking realization that there’s an endless supply of bugs surrounding time handling …
“GandK-Geoff” wrote:
“TheEndless” wrote:
you’d want to make sure the initial date is GMT prior to the calculationRight, but that may not be easy to manage in all circumstances.
I don’t really view calculations in GMT as a subset of the general problem. IMHO the right way to handle date/time is to do all calculations in epoch-based GMT times, and only use the broken-down form (day,month,year,etc) for display. Time zones and DST take part in the conversion of an internal epoch date to a displayable form but they don’t affect any date calculations, such as the duration between two dates or the date X days before/after a given date, which can be done easily using epoch based dates.
–Mark
“RokuMarkn” wrote:
I don’t really view calculations in GMT as a subset of the general problem.
Well … it is an it isn’t. “Having your inputs already in GMT” is the subset I was referring to – those cases when you don’t have to convert your inputs from local time to GMT in the first place. But see below for other ways in which this might be considered a subset.
“RokuMarkn” wrote:
IMHO the right way to handle date/time is to do all calculations in epoch-based GMT times, and only use the broken-down form (day,month,year,etc) for display.
That is an excellent first approximation of correctness, especially if nasty bits like leap seconds, range limitations, etc. can be safely ignored (which is really the vast majority of the time, no pun intended). You can get a little better for some use cases by using TAI instead, but most people these days expect GMT calculation for non-scientific needs, so it’s a good default. Once you get into scientfic uses, all bets are off, and there are time bases galore for special purposes.
“RokuMarkn” wrote:
Time zones and DST take part in the conversion of an internal epoch date to a displayable form but they don’t affect any date calculations, such as the duration between two dates or the date X days before/after a given date, which can be done easily using epoch based dates.
That is indeed a common choice of interpretation that doesn’t always DWIM unfortunately. For a simple example of why this is not necessarily correct, try this: “What is the duration in hours between noon January 1, 2010 and noon July 1, 2010?” Is the person asking for actual hours they lived in the six months between those two dates in their local timezone? Or are they looking for the answer in the ‘floating’ timezone, the abstract zone in which no DST occurs and the conversion to GMT is undefined, but for which a day always equals 24 hours? Would they be surprised if the answer was exactly divisible by 24, or if it wasn’t?
Sure, if you’re doing only date math (with “day” as the smallest unit), that issue doesn’t occur. But then there is no defined conversion to epoch seconds (regardless of timezone). To make sure you only deal with round days and avoid rounding errors, you might convert to a timezone with no leap seconds. But since most system libraries do things in GMT, you’d have to do your own correction anyway, so you might as well do the math in RD (Rata Die) days and be done with it.
(Please excuse the pedantry, BTW. Unfortunately “time” (like “character set”) is such a slippery concept that it is unreasonable to expect anyone to simultaneously understand it completely and actually get useful work done. For the rest of us, it’s probably most important to simply know that the rules of thumb are only that, and don’t always apply. I know that I was in for a serious mental shock when I first began to study this stuff. “There is unexpected depth in all fields of endeavor.”)
Ok, let me break this down so I understand it:
nowDate = CreateObject(“roDateTime”)
'create nowDate as an roDateTime object
nowDate.Mark()
'set nowDate to current Time
calcDateSeconds = nowDate.AsSeconds() - (numDays * 60 *60 * 24) 'number of days * seconds in minute * minutes in hour * hours in day
'so .asSeconds gives the time since the beginning of the “Unix Epoch” in seconds; now we have something we can actually do calculations on
'numdays is the variable for how far in the past I want go to find the Year, Month and Day
'numdays * 60 seconds * 60 min
calcDate = CreateObject(“roDateTime”)
’ ok, we created another rodatetime object here
calcDate.FromSeconds(calcDateSeconds)
'ah, so this converts seconds to a date based on the Unix Epoch.
'the object ref. manual says: • Initialize the date/time value using the number of seconds from epoch.
calcDate.ToLocalTime()
This converts the UTC to my local time.
So far this is most poorly written section of the Component Reference, hey Roku guys, can you please add more details and update this, not for me, but for anyone else trying to learn Brightscript?
Thanks everybody for this enlightening discussion.
- Joel
“jbrave” wrote:
Ok, let me break this down so I understand it:
.
.
.
Bah! Comments! Who needs 'em!
Sounds like you’ve got it.. The .ToLocalTime() line is only necessary if you’re working with actual time values, in which case you may need to be sensitive to the other issues discussed in this thread. If you just want a date, then you don’t need it.
