Mudlet 2.1 Database Problem

[Vadi]

Done, thank you.

[Jor'Mox]

Looking at your function to calculate the time difference, it looks to me like it will always use the current time difference (which changes based on if I am on daylight or standard time). So if I try to display a timestamp from December, it will still use the current time difference, instead of the time difference that would apply for December, meaning it will display the time as one hour different from what it should be. If you use this instead, it should use the timestamp itself to determine what the time difference should be (which should generate correct times).

Code: [show] | [select all] lua

local function calculate_UTCdiff(ts)
   local utc = os.date('!*t',ts)
   local lcl = os.date('*t',ts)
   lcl.isdst = false
   return os.difftime(os.time(lcl), os.time(utc))
end

Then you just have to pass it the timestamp when you call it, and it should work perfectly. I think.

[Vadi]

"remote" times is where it gets complicated. See http://lua.2524044.n2.nabble.com/os-tim ... 61931.html and https://github.com/stevedonovan/Penlight/issues/89, and subsequently https://github.com/stevedonovan/Penligh ... te.lua#L77 which is more evolved and still the author of that knows it doesn't quite work right.

[Vadi]

I don't think we want the time displayed to be relative to the time it was made at. We're looking at the timestamp now... if the timestamp was made at 23:00 of a day when the next day the clock is advanced by +1, and we go look at the timestamp at 2am which would be an hour away from 23:00 because the clock was moved, we would expect the timestamp we made to have a 1 hours worth of difference from now, but two as this solution would create. So we'd expect the timestamp to say 1am because we made it an hour ago.

I think timestamps should be relative to now because of this. The other way, while seeming more 'proper', is more confusing and not actually batter.

[Jor'Mox]

Isn't the whole point of a clock to make time objective rather than subjective? And, even ignoring that, you are arguing that we should have the returned time for a Timestamp change based on when it is accessed, just because of edge affects that happen twice a year?

If I make a Timestamp today at 12:00, I would want it to say 12:00 all the time, regardless of when I looked at it. While I agree that the transitions can be confusing, noon is always noon, and 5pm is 5pm and so on. 5pm doesn't suddenly become 4pm just because I'm looking back at today from December.

This wouldn't be SO bad if you had an option to retrieve the time as stored (UTM), as that would obviously be constant. But with things as is, I feel I would be better off writing my own Timestamp instead of using the included functionality, or at the very least overwriting the functions used to change the UTM epoch value into local time, so that I can get consistent results.

In respect to calculating time differences for now as opposed to for some distant time, I fail to see how there would be a difference, since both calculations are made using an epoch value and a standard function. If the standard function behaves incorrectly for a given time, it will do so even when that time is right now, as well as if it is 10 years from now.

[Vadi]

I'm brainstorming on the best way to handle this, because it does need to be discussed as doing it wrong will cause problems, confusion and frustration.

I think the best way forward is to look up how major libraries handle this case: showing a timestamp in another DST period in the current time. Then look at popular opinions/feedback of the said major libraries and their date handling.

[Vadi]

I've posted on http://programmers.stackexchange.com/qu ... r-then-dst for some feedback.

[Vadi]

Qt's function handles it in the 'local time at that time' manner:

(09:18:48) vadi: When QDateTime::toLocalTime() is used, is the current DST offset applied, or the timestamps DST offset?
(09:21:22) thiago: it's the local time at that time

(thiago is a long-time Qt contributor, now works for Intel doing Qt work)

Which would lean towards the persistent time all the time idea.

[Jor'Mox]

So, based on what I'm reading from your post on stack exchange, they seem to be advocating calculating time difference for the time of the timestamp, rather than using the current time difference. Yes? Or am I misreading that?

[Vadi]

Yep! So your way will go forward.