1

Suppose a user of your website select days times and account timezone:

2015-09-02 14:15:00 
2015-09-02 15:30:00
2015-09-03 17:10:00

Timezone: "America/Los_Angeles"

You send and keep this information at the server and the server should execute A function at the exact same local time the user needs it. At later time the user can change his timezone to "Europe/Stockholm" and we re-adjust the dates by this timezone.

How should the flow from client to server should look like? What are my actions? There is a lot of wrong and misinformation over the internet I really need some solid advice.

Here is what I came up with:

I save this javascript object to the database moment.tz("2015-09-02 14:15:00", "America/Los_Angeles").toDate()

and based on this date I execute the function and if we need to recalculate the timezone we just take days/times and use the same thing.

I have read that this way might not be adjusted to day light saving time and it's wrong. Help?

Boris Daka
  • 603
  • 2
  • 17
  • 33

1 Answers1

1

I'll answer this by dissecting your question into the relevant parts.

... the server should execute A function at the exact same local time the user needs it.

Ok, so I'll assume you are scheduling events to run in the future. This is important, as the approach would be completely different if you were recording timestamps for events that have already occurred.

... at later time the user can change his timezone to "Europe/Stockholm" and we re-adjust the dates by this timezone.

You should not adjust the dates of the events. Associate the time zone with the event, not with the user. You can have a per-user time zone also, and you can adjust for that time zone on display - but you should leave the original event time and time zone alone unless the user directly edits it. (Note, I'm making several assumptions about your project internals here, but this is best general advice).

I save this javascript object to the database moment.tz("2015-09-02 14:15:00", "America/Los_Angeles").toDate()

The JS Date object represents an instant in time, but projects it using the local time zone of where the code is running. Therefore, any time zone adjustment you do with moment-timezone will be undone as soon as you call toDate. You should avoid calling toDate. Instead, use moment's functions, such as format, which can retain the time zone offset.

I have read that this way might not be adjusted to daylight saving time and it's wrong.

Not sure where you read that, but that's incorrect. Both the Date object and a moment object (whether using moment-timezone or not) can properly account for DST.

You may also wish to review some of the other answers I've written about scheduling future events. Start with this one, and follow links to other posts.

Community
  • 1
  • 1
Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • thank you for a really great answer, So it's good to know about toDate() how can I save it to the database as a date object? I need to have a date for the queue processor job I'm using so it requires next event occurrence not all future events. So do you know how can I use moment timezone to convert a true js date object I can save to the database? or my only way of doing this is to make the queue worker to use moment time zone date? But still this seems complicated. I don't know how the queue worker intercept dates. And when to really run the job. – Boris Daka Sep 03 '15 at 12:52
  • Sorry, I'd have to know a lot more about your architecture to be able to answer that. But in general, `Date` objects aren't stored into a database - only their *values* are. A particular data access API may expect objects in a certain form, but it will still have read and serialize that object before it can write it to the form the database expects. – Matt Johnson-Pint Sep 03 '15 at 16:18
  • Also consider that your data access mechanism might be looking at the local value of the `Date` object, but it could very well instead be looking at the UTC equivalent value, such as the timestamp result of `.getTime()` or `.valueOf()`, or the string result of `.toISOString()` or `.toUTCString()`. If it stores the UTC time, then you're good to go - since it reflects the same instant in time you intended the job to run. – Matt Johnson-Pint Sep 03 '15 at 16:23
  • awesome thanks a bunch it definitely sinks in now. I think I can figure out how to handle it now thanks a lot! – Boris Daka Sep 04 '15 at 04:42