www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Can Walter stop living in the future? (meta)

reply WebFreak001 <d.forum webfreak.org> writes:
Hey Walter, I think you are a time traveler. [1]

this breaks the ordering in the forum, it looks weird and it 
breaks our discord bot because it's based on time. [2]

So uh can you come back to the present?

(In all seriousness, does someone know why this happens and if it 
can be fixed on the forum side? I use the RSS feed to track the 
announce forum and inside feed/entry/published the timestamp just 
for Walter just seems to have a 1 hour offset time, even though I 
take the timezone, which is -07:00h, into account. This has 
happened twice so far and I'm just assuming the published entry 
would be something controlled by the server)

[1] Screenshot on the forums: 
https://cdn.discordapp.com/attachments/242094594181955585/578111915528552449/unknown.png
[2] Broken discord news bot, posting the news 6 times because it 
is posted 1 hour in the future: https://wfr.moe/faKn9x.png
May 15 2019
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/15/19 3:55 PM, WebFreak001 wrote:

 Hey Walter, I think you are a time traveler. [1]
 
 this breaks the ordering in the forum, it looks weird and it breaks our 
 discord bot because it's based on time. [2]
 
 So uh can you come back to the present?
 
 (In all seriousness, does someone know why this happens and if it can be 
 fixed on the forum side? I use the RSS feed to track the announce forum 
 and inside feed/entry/published the timestamp just for Walter just seems 
 to have a 1 hour offset time, even though I take the timezone, which is 
 -07:00h, into account. This has happened twice so far and I'm just 
 assuming the published entry would be something controlled by the server)
 
 [1] Screenshot on the forums: 
 https://cdn.discordapp.com/attachments/242094594181955585/5781119155
8552449/unknown.png 
 
 [2] Broken discord news bot, posting the news 6 times because it is 
 posted 1 hour in the future: https://wfr.moe/faKn9x.png


My guess, Walter was in the UK for a week, had his time set up manually, 
or something else, and then when came back, he didn't set the time 
correctly. Or his computer is set to auto-detect the time zone, and 
that's not working right at the moment.

On the plane, I set my time manually to UK time so I could see what the 
time was going to be when I arrived back home.

It would be cool if the server just re-timestamped things if they are so 
far out of date (+/- 30 minutes should be enough). I've had posts from 
the PAST show up, because my outbox for some reason got stuck, and I 
didn't notice for a few days.

-Steve
May 16 2019
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/16/2019 8:59 AM, Steven Schveighoffer wrote:

 My guess, Walter was in the UK for a week, had his time set up manually, or 
 something else, and then when came back, he didn't set the time correctly. Or 
 his computer is set to auto-detect the time zone, and that's not working right 
 at the moment.


I didn't take my desktop to the UK :-)

I did discover the problem. The black hole generator I was working on as a side 
project had power surge, which caused a temporary rip in the space-time 
continuum and my house went forward an hour without my noticing. I replaced the 
capacitors in the power supply and things are back to normal now. Nothing to 
worry about.
May 16 2019
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 16, 2019 at 09:21:19AM -0700, Walter Bright via Digitalmars-d wrote:
[...]

 I did discover the problem. The black hole generator I was working on
 as a side project had power surge, which caused a temporary rip in the
 space-time continuum and my house went forward an hour without my
 noticing. I replaced the capacitors in the power supply and things are
 back to normal now.  Nothing to worry about.


Did you check to make sure that the polarity hasn't been inadvertently
reversed?


T

-- 
Creativity is not an excuse for sloppiness.
May 16 2019
next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/19 12:48 PM, H. S. Teoh wrote:

 On Thu, May 16, 2019 at 09:21:19AM -0700, Walter Bright via Digitalmars-d
wrote:
 [...]

 I did discover the problem. The black hole generator I was working on
 as a side project had power surge, which caused a temporary rip in the
 space-time continuum and my house went forward an hour without my
 noticing. I replaced the capacitors in the power supply and things are
 back to normal now.  Nothing to worry about.




Don't ya just hate when that happens?


 Did you check to make sure that the polarity hasn't been inadvertently
 reversed?


Hasn't Starfleet training taught us anything? Reversing the polarity is 
always the clever *solution*, not the problem!
May 16 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/16/2019 9:48 AM, H. S. Teoh wrote:

 Did you check to make sure that the polarity hasn't been inadvertently
 reversed?


Criminy! I forgot about that! Ju++s+t ++++t++++++r+y++++ng +it++++ n++++++o+w. 
+HH+++an+++g ++o+++n a +++mo+++++m+++en++t ...............   ......... <signal
lost>
May 16 2019
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, May 16, 2019 4:47:22 PM MDT Walter Bright via Digitalmars-d 
wrote:

 On 5/16/2019 9:48 AM, H. S. Teoh wrote:

 Did you check to make sure that the polarity hasn't been inadvertently
 reversed?


 Criminy! I forgot about that! Ju++s+t ++++t++++++r+y++++ng +it++++
 n++++++o+w. +HH+++an+++g ++o+++n a +++mo+++++m+++en++t ...............
 ......... <signal lost>


Uh, oh. We really don't want to lose Walter. :)

- Jonathan M Davis
May 17 2019
prev sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Thursday, 16 May 2019 at 22:47:22 UTC, Walter Bright wrote:


 Criminy! I forgot about that! Ju++s+t ++++t++++++r+y++++ng 
 +it++++ n++++++o+w. +HH+++an+++g ++o+++n a +++mo+++++m+++en++t 
 ...............   ......... <signal lost>


In your avatar, I swear the tippy-top of your hair is fading 
away...
May 17 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/17/2019 4:45 AM, Ron Tarrant wrote:

 In your avatar, I swear the tippy-top of your hair is fading away...


It's been fading away since I was a teenager.

It's nice to not have to worry anymore about hair gels, blow dryers, expensive 
hair cuts, bed head, helmet hair, getting it caught in the drill press,
feathery 
creatures nesting in it, etc.
May 17 2019
parent Ron Tarrant <rontarrant gmail.com> writes:
On Friday, 17 May 2019 at 14:16:13 UTC, Walter Bright wrote:

 On 5/17/2019 4:45 AM, Ron Tarrant wrote:

 In your avatar, I swear the tippy-top of your hair is fading 
 away...


 It's been fading away since I was a teenager.

 It's nice to not have to worry anymore about hair gels, blow 
 dryers, expensive hair cuts, bed head, helmet hair, getting it 
 caught in the drill press, feathery creatures nesting in it, 
 etc.


Wait a moment! This has nothing to do with time travel, does 
it!??! :)
May 18 2019
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 16, 2019 at 11:59:48AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]

 It would be cool if the server just re-timestamped things if they are
 so far out of date (+/- 30 minutes should be enough). I've had posts
 from the PAST show up, because my outbox for some reason got stuck,
 and I didn't notice for a few days.


[...]

Seriously, everyone should just store (and transmit) all dates in UTC
always. Let the software format it according to the local timezone when
it needs to be displayed.  Then there would be no problems.

But alas, I only dream...


T

-- 
Don't modify spaghetti code unless you can eat the consequences.
May 16 2019
parent reply Johannes Loher <johannes.loher fg4f.de> writes:
On Thursday, 16 May 2019 at 16:46:13 UTC, H. S. Teoh wrote:

 On Thu, May 16, 2019 at 11:59:48AM -0400, Steven Schveighoffer 
 via Digitalmars-d wrote: [...]

 It would be cool if the server just re-timestamped things if 
 they are so far out of date (+/- 30 minutes should be enough). 
 I've had posts from the PAST show up, because my outbox for 
 some reason got stuck, and I didn't notice for a few days.


 [...]

 Seriously, everyone should just store (and transmit) all dates 
 in UTC always. Let the software format it according to the 
 local timezone when it needs to be displayed.  Then there would 
 be no problems.

 But alas, I only dream...


 T


Unfortunately, this is actually not sufficient for all use cases. 
Not all dates are points in time, while dates in UTC are. E.g 
changes to timezones happen more often than you‘d expect. What if 
you set your alarm to 7:00 AM in a given timezone and then the 
timezone is adjusted to one hour earlier. Do you want to go your 
alarm to go off at 8:00 AM in that timezone now, which would be 
what you‘d get if the time was stored in UTC? Probably not, you 
want it to still go off at 7:00 AM in that timezone. Handling 
dates and time can be unexpectedly more difficult than one 
believes at first.
May 16 2019
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/19 3:24 PM, Johannes Loher wrote:

 On Thursday, 16 May 2019 at 16:46:13 UTC, H. S. Teoh wrote:

 Seriously, everyone should just store (and transmit) all dates in UTC 
 always. Let the software format it according to the local timezone 
 when it needs to be displayed.  Then there would be no problems.


 
 Unfortunately, this is actually not sufficient for all use cases. Not 
 all dates are points in time, while dates in UTC are. E.g changes to 
 timezones happen more often than you‘d expect. What if you set your 
 alarm to 7:00 AM in a given timezone and then the timezone is adjusted 
 to one hour earlier. Do you want to go your alarm to go off at 8:00 AM 
 in that timezone now, which would be what you‘d get if the time was 
 stored in UTC? Probably not, you want it to still go off at 7:00 AM in 
 that timezone. Handling dates and time can be unexpectedly more 
 difficult than one believes at first.


Fair point. My analysis of this:

"UTC vs Local Time" is basically "absolute vs relative". UTC is a 
specific, unambiguous, point in time, period. Local time is UTC viewed 
through a chosen filter (and it's a filter that's not necessarily 1:1 
(example: daylight savings time), which makes things extra fun).

So the choice of "UTC vs Local" is analogous to filesystem paths 
(absolute vs relative paths). Accordingly, the question should be "Am I 
referring to a very specific, unambiguous point in time? Or am I 
referring to a local perspective of time?" Much like HSTeoh, I strongly 
suspect the vast majority of cases should be absolute time (ie, UTC, 
with local time being treated as a presentation-layer detail).

But you bring up the idea of a user setting an alarm...and that raises 
an interesting wrinkle...As I see it, the problem here stems from the 
fact that there are potentially *TWO* different perspectives (ie "time 
zones") involved: (keeping in mind that "time zone" can also refer to 
daylight-savings status)

Perspective A: The time zone (or daylight-savings status) of the user 
when they set the alarm.

Perspective B: The time zone (or daylight-savings status) of the user 
when the alarm sounds.

(Note that this is NOT an "absolute vs relative" distinction, but a 
distinction between two different relative perspectives: Kind of like 
"~" vs "." in filepaths.)

Since all user-input involving time should naturally be considered to be 
relative to the user's own perspective (unless the user specifically 
states otherwise), this creates a dilemma because there are *two* user 
perspectives: Is the user entering a time relative to their current 
perspective ("time zone") of time? (Ie, "A"). Or are they entering a 
time relative to their own future self *at the moment of the alarm*? 
(ie, "B").

To be perfectly honest, I think any "set alarm" interface that doesn't 
clarify this "time-when-setting-alarm vs time-when-sounding-alarm" 
distinction is an inherently ambiguous interface from the user's 
perspective (not that most users are likely to notice this ambiguity 
unless its pointed out). So I agree this is a difficult situation to 
solve...*however*...I think it's difficult to solve *because* of 
competing perspectives (ie, competing local time zones and/or competing 
local daylight savings statuses), and NOT because of absolute ("UTC") vs 
relative ("local" time...but *which* local time, "upon-setting" or 
"upon-activation"?).

Ultimately, the software (combined with its communication to the user) 
has to make a choice as to which user perspective the alarm's time is 
relative to: The user when setting the alarm, or the user when receiving 
the alarm.

In any case, if the user's (admittedly unlikely) desire is unambiguously 
A: "use the user's perspective when setting the alarm", then I'll admit 
that despite being unlikely, the user in this case clearly *wants* to be 
woken at *local* 8 o'clock in your example (ie, "Activate the alarm at 
the point that will be 7 o'clock in the time zone I'm in right now while 
I'm setting the alarm"). So the time they enter should immediately be 
converted to UTC and stored as UTC so that later on, any current "now" 
local time can be converted to UTC and compared with the absolute 
desired point in time to determine if sounding an alarm is warranted.

On the other hand, in the (more likely) case the user's desire is 
unambiguously B: "use the user's perspective when they are BEING 
AWAKENED by the alarm", then obviously it is impossible to predict the 
user's future time zone. Therefore, a UTC CANNOT be chosen 
ahead-of-time. So when the user sets the alarm, the software must store 
the alarm's time NOT as an unambiguous UTC, but as a time that's 
*relative* to whatever selected timezone (or daylight-savings status) 
may be "active" when the alarm is sounded. This means storing just 
simply a local (ie, relative, non-UTC) time and then later, upon 
checking whether the alarm should be sounded...converting the UTC of 
*now* to the time zone the user is in, and comparing *that* to the 
relative time ("7am"?) stored as the alarm trigger.
May 16 2019
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, May 16, 2019 10:43:55 PM MDT Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:

 But you bring up the idea of a user setting an alarm...and that raises
 an interesting wrinkle...As I see it, the problem here stems from the
 fact that there are potentially *TWO* different perspectives (ie "time
 zones") involved: (keeping in mind that "time zone" can also refer to
 daylight-savings status)

 Perspective A: The time zone (or daylight-savings status) of the user
 when they set the alarm.

 Perspective B: The time zone (or daylight-savings status) of the user
 when the alarm sounds.

 (Note that this is NOT an "absolute vs relative" distinction, but a
 distinction between two different relative perspectives: Kind of like
 "~" vs "." in filepaths.)

 Since all user-input involving time should naturally be considered to be
 relative to the user's own perspective (unless the user specifically
 states otherwise), this creates a dilemma because there are *two* user
 perspectives: Is the user entering a time relative to their current
 perspective ("time zone") of time? (Ie, "A"). Or are they entering a
 time relative to their own future self *at the moment of the alarm*?
 (ie, "B").


A similar though subtly different use case is putting an appointment in your
calendar when you're currently in a different time zone than the appointment
will be. And the fact that we now carry devices in our pockets that get used
for stuff like this makes it far more likely that stuff like this will come
up - though it can happen without you even moving time zones. For instance,
at a previous job, we were supposed to mark in Outlook when we were taking
PTO, and I was in a different time zone from my eomployer. And since Outlook
treated makring a day as marking a specific 24 hour period, I'd mark a day
on the West Coast and end up with it showing something like 03:00 - 02:59
when folks looked at it on the East Coast. And if you didn't look at the
exact times when looking at it on the calendar, I think that it managed to
make it look I was taking two days off instead of one.

Coming up with a way to deal with stuff like this in a way that doesn't run
afoul of time zone problems can be really hard - especially since people
don't tend to think about these things the same way computers do. The
absolute vs relative path analogy is an interesting one though.

- Jonathan M Davis
May 17 2019
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Always thought second pecision is an overkill, day number should 
be enough.
May 16 2019
prev sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Wed, 15 May 2019 at 17:00, WebFreak001 via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Hey Walter, I think you are a time traveler. [1]

 this breaks the ordering in the forum, it looks weird and it
 breaks our discord bot because it's based on time. [2]

 So uh can you come back to the present?


It's you who's living in the past. :-)

-- 
Iain
May 17 2019