Lang and Times

[Midnight Modding]

I'm sometimes getting things a bit mixed up on times and lang bits, due to differences dependent on the methods used.

1. In the past, I used $la = \IPS\Member::loggedIn()->language()->addToStack('key') in the php file and passed $la to the template. Then simply putting {$la} in the template wouldn't work because it just displayed the unique key returned by addToStack(). So I used {lang="$la"} in the template, which worked. HOWEVER, another time in my template I put {$row->la} where my model had a getter with that name... the getter returned \IPS\Member::loggedIn()->language()->addToStack('key') and yet that worked, without using {lang=""}. So why does it sometimes work without lang="" and other times it doesn't? Is it related to when in the output process you're calling addToStack()?

I think i've even had a getter return \IPS\Member::loggedIn()->language()->addToStack('key') . 'somethingElse' and it worked, so that's what gets confusing because some places it displays the actual unique key and sometimes the string and sometimes they can be mixed and soemtimes they can't.

2. times get confusing, as well... \IPS\DateTime::create() gives the time in UTC. \IPS\DateTime::ts() gives it in the user's time zone. In our form validation checks, is the user's submitted time still in their tz, or it's been converted back UTC? I just noticed I am comparing their data to create(). Also I've seen first party apps use create() as default form field times/dates. But that will be a different tz than theirs.

I sure thought docs said create() would give the time in the user's tz... but it doesn't so I just used ts( time() ).

I think I mostly have this all striaight, but then at times I get mixed up again, so figured someone may be able to keep me straight on it all.

[Midnight Modding]

On a side note, I wish the datetime plugin would allow for always showing times AND use relative. As it is now, you either have to have it not show times for far off dates or use norelative.

I see why it's done this way, as most apps would not need times for a date that isn't recent. But, for me, I do need times showing, especially for future dates. (havent looked at calendar events... maybe that has some interesting methods).

I think in the past versions I also coded it to be able to use relative for future dates, also, which would be nice here. In 4.x I did get formatInterval() working, though, so that's pretty nice.

[bfarber]

1) When you use addToStack() you get a unique key that is then replaced out with the actual language string value during output. It should work fine no matter if you call it from a PHP source file, or use the {lang=""} plugin in a template (which simply does the same thing). The only times this wouldn't work is if you (a) somehow adjusted the key that was returned, (b) you used addToStack() against one language but then output in a different language, or (c) you didn't output through \IPS\Output::i()->sendOutput() (and didn't manually replace the language string replacements).

2) \IPS\DateTime::create() returns a new datetime object instance in the native server time zone. Using our custom ts() method is an option to get the timezone set immediately, or you could also do something like this:

$date = new \IPS\DateTime( "now", new \DateTimeZone( \IPS\Member::loggedIn()->timezone ) );

3) We don't really support relative times for future dates presently.

[Midnight Modding]

Well, I definitely understand why printing or var dumping the addToStack() result wouldn't work, but I could have sworn that I simply tried to output it in the template with {$var} and it not working. I'll play around with it again at some point, to see if I am just misremembering. I generally just use {lang=""}, now, though.

I assume the unique key has some info for it to be recognized as a lang bit key. What got me confused is I thought {lang=""} was required all the time when using addToStack() results or it wouldn't be known that the key is from a lang bit. If the unique key has info to where it's always recognized during output as a lang bit, then it makes sense now how I can append strings to it and it still work.

Anyway, thanks! Hopefully I will keep it all straight. I just sure thought I ran into some issue with it showing the key even when trying to use it in the template, but I am basing this off of memory.... didn't happen recently.

[Midnight Modding]

oh, also, what about dates/times submitted on a form helper form? I know they are treated as in the user's timezone at time of submit, but are they still in that same time zone during our validation checks or have they already been converted to UTC?

I can obviously test, but I'm just constantly working on so many areas it's getting overwhelming and I'm trying to concentrate on another area first.

[bfarber]

Depends on the form helper. If the 'timezone' option is set to NULL (the default) then the time will be in the submitter's time zone, yes.

[Midnight Modding]

46 minutes ago, bfarber said:

Depends on the form helper. If the 'timezone' option is set to NULL (the default) then the time will be in the submitter's time zone, yes.

Just to be sure there's no miscommunication, you're saying it stays that way even through our validation checks, right?

And, yes, I do leave it as NULL. I'm going to have to go change a lot of checks because I remember I compared their submitted times to create().

[bfarber]

Yes, although I have to wonder.......what validation checks are you running where the timezone matters that much?

[Midnight Modding]

31 minutes ago, bfarber said:

Yes, although I have to wonder.......what validation checks are you running where the timezone matters that much?

I have to make sure that some submitted times are future times, so I thought I had to be sure that the current time and the submitted time are in the same timezone.

Although... I just realized... since they are both DateTime objects, comparisons will work with them not in the same timezones, right? So i guess I am fine anyway! I didn't think about that.

I got mixed up, thinking I was dealing with timestamps where 1 time was converted with 1 timezone and 1 with another, ie not an equal comparison. I forgot I am comparing DateTime objects. I'm seriously thinking about so much at once, I am mixing myself all up.

[bfarber]

Exactly.

Alternatively, timestamps are NOT timezone dependent, so you can always do $datetime->getTimestamp() < $otherDatetime->getTimestamp()

[Midnight Modding]

10 hours ago, bfarber said:

Exactly.

Alternatively, timestamps are NOT timezone dependent, so you can always do $datetime->getTimestamp() < $otherDatetime->getTimestamp()

yes I know if they are correctly converted to timestamps, there's no problem there. I'm not sure what was going through my head. I guess what I thought I was doing was comparing 2 strings where it was times without timezones taken into consideration yet. I have it all straight now. lol. Also, it makes more sense to me now how DateTime objects can be convenient, as well, for quite a few reasons.