Roku Developer Program

[TheEndless]

"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.

[GandK-Geoff]

"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 ....

[RokuMarkn]

"GandK-Geoff" wrote:

"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.

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

[GandK-Geoff]

"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.")

[jbrave]

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

[TheEndless]

"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.