Jump to content

Daylight Savings Time bug in note created time.


drivera

Recommended Posts

  • Level 5*

Interesting. Time stuff like this gives me heartburn (fortunately, I don't need to deal with it all that often). If this is a problem, them I would tend to believe that it's a reporting problem, and not a data corruption problem : Evernote returns timestamps as UTC in its API (at a guess, that's what it's storing on its servers), and it looks like displays those timestamps relative to local time. So, for example, if you change your time zone via Control panel, those time stamps are reported local to the new time zone. Not only that, but changing your time zone also affects the dates that WIndows reports as well.

 

I don't know whether this hinders or helps, but it's somewhat consistent behavior. Good times.

Link to comment

I wonder if this is just local, and possibly just being recorded wrong, because of the DST change?

 

What does it say in the web client, which is the main source/location of your notes.

 

 

Side note, I guess I have to find out when the UK decides to mess with the clocks...Sigh...

Link to comment
  • Level 5*

Good point Scott. I tried this with Chrome. From my exhaustive tests (kidding), Chrome will pick up the Windows time settings on startup only. Here's what I did:

* Set the current time zone from Atlantic to pacific.

* Did a web clip

* Fired up the Evernote web client

* The new web clip reflected my actual Atlantic local time; hmmm, that web client must be really smart!!

* Oh wait: restart Chrome, and fire up the web client again

* Now the note reflects the OS' Pacific local time

Link to comment
  • 11 months later...

If the Evernote main database (accessed via the Web client) isn't storing dates in UTC, well, there's no hope for this product, and the entire dev team should be severly spanked. But I am fairly certain that is not the case!

 

More likely, it is a localization / display problem.  Meaning: the client you are using (desktop, phone, web, etc) either:

  1. asks the underlying platform (OS, phone OS, browser) what the local time settings are, calculates the offset from UTC, and converts all dates before displaying them, OR
  2. Hands the time in UTC to an API layer and tells the layer to convert the UTC time to local time, display it in a certain location, format, etc.)

Problems still crop up if the user sets their time zone wrong or disables the switch from EST to EDT. That isn't Evernote's responsibility, but also, it isn't the cause of the problem reported in the original post.

 

Problems still crop up because different platforms can have different definitions of daylight savings time!  For example, in the US, they sometimes change the calendar so that DST starts earlier or later than it used to. This would be the responsibility of the underlying platform.

 

But, sometimes developers will handle problems with the underlying platform by programming a workaround.  E.g. Suppose DST starts on Sun, 3/8 at 2 am, but the underlying platform hasn't been updated, and thinks DST starts two weeks later on 3/22. A developer might write a rule similar to if date > 3/8 0200 and date < 3/22 0200 then add 1 hour to the UTC offset.  This rule could be implemented at the application level (e.g. Evernote) or below that (e.g. a browser's timedate functions implement the workaround in response to a broken OS).  Later, the underlying problem is fixed, but the dev who did the workaround doesn't know this, so their workaround creates a new bug.

 

Sadly, I have to report yet another DST bug. In the Windows client, a day or so before DST begins, set a reminder on a note for 1 week in the future at 8 am. Sync. Then wait until after DST begins. Your note's reminder is now set to 9 am.  WTF?

 

Normally I would open a new post to report this bug, and test this in desktop, phone, and web clients, and document the whole thing. But honestly, why bother? Nothing's going to get done :angry::excl: :excl: :excl: :excl:

Link to comment
  • Level 5*

If the Evernote main database (accessed via the Web client) isn't storing dates in UTC, well, there's no hope for this product, and the entire dev team should be severly spanked. But I am fairly certain that is not the case!

 

It appears to be the case. From the Evernote API: https://dev.evernote.com/doc/reference/Types.html#Typedef_Timestamp

Link to comment

Are you running the current release (5.8.4)? There was a fix for UTC->Localtime conversion that went into that release.

 

Thanks for the tip. A day or so ago, updated to Win client 5.8.4.6870 (247870). Just now checked the reminder date on another note that was created before the change to DST.  The reminder time was still off by one hour. So it now appears that all the reminders set before DST will be wrong until I manually correct them.

 

Is this a problem on the Web client?  What about a note created before DST on Web client, but viewed after DST on Win client?  What about the converse situation? What about these situations on Android? Mac? Still too annoyed to document this problem in all possible scenarios...and I shouldn't have to!  Based on my description, EN staff should have no trouble imagining the scenarios and testing for them.

 

- J

Link to comment
  • Evernote Employee

Are you running the current release (5.8.4)? There was a fix for UTC->Localtime conversion that went into that release.

 

Thanks for the tip. A day or so ago, updated to Win client 5.8.4.6870 (247870). Just now checked the reminder date on another note that was created before the change to DST.  The reminder time was still off by one hour. So it now appears that all the reminders set before DST will be wrong until I manually correct them.

 

Is this a problem on the Web client?  What about a note created before DST on Web client, but viewed after DST on Win client?  What about the converse situation? What about these situations on Android? Mac? Still too annoyed to document this problem in all possible scenarios...and I shouldn't have to!  Based on my description, EN staff should have no trouble imagining the scenarios and testing for them.

 

- J

Times on Windows should be correct whether they were created before or after the DST change. Times are stored in UTC and displayed according to the local systems time settings. I just compared a number of notes before/after and the time was looked correct - on both the Windows client and Web client.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...