861812 - Provide .getDSTOffset() for the Date object

Status: RESOLVED INCOMPLETE

(Core :: DOM: Device Interfaces, defect, P3)

Description

[Gene Lian (I already quit Mozilla)]

This is inspired by bug 857545, comment #23. We're hoping to provide a .getDSTOffset() DOM API for the Date object (similar to .getTimezoneOffset()) to get the current system Daylight Savings Time (DST) offset, which is useful for some user scenarios (e.g., the UI needs it to show some DST info to end users).

Comment 1

[Justin Lebar (not reading bugmail)]

dbaron, is this a reasonable thing?  I'm not sure Date()'s contain this level of timezone info; maybe this getDSTOffset() method would have to go somewhere else.  All we care about is the system's DST offset; we're assuming here we can get the system timezone offset from |new Date()|.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to Justin Lebar [:jlebar] from comment #1)
> dbaron, is this a reasonable thing?  I'm not sure Date()'s contain this
> level of timezone info; maybe this getDSTOffset() method would have to go
> somewhere else.  All we care about is the system's DST offset; we're
> assuming here we can get the system timezone offset from |new Date()|.

By "system's DST offset" did you mean "system's UTC offset"?

And what do you mean by a DST offset?  The offset from non-DST time to DST time (usually 1 hour, but 0.5 hours for Australia/Lord_Howe)?  Or the offset from UTC to the DST time?  Either way, though, I don't see how this is useful without knowing whether the current UTC offset has DST or not.

The semantics seem a bit odd for a decent number of edge cases, though.  For example, in a zone that has observed daylight savings time in the past but has stopped doing so, what does this method return?  When does it change as the rules for that zone transition?

Comment 3

[Justin Lebar (not reading bugmail)]

> By "system's DST offset" did you mean "system's UTC offset"?

I meant "the difference between this computer's current time and the time it would have if it were in the same timezone, but was not observing DST," although there are of course other ways to convey that same bit of information.

Your point about historical DST suggests that the Date object is probably not the right place for this.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to Justin Lebar [:jlebar] from comment #3)
> > By "system's DST offset" did you mean "system's UTC offset"?
> 
> I meant "the difference between this computer's current time and the time it
> would have if it were in the same timezone, but was not observing DST,"
> although there are of course other ways to convey that same bit of
> information.

That actually seems like a more reasonable alternative than the two I suggested.

Comment 5

[Gervase Markham [:gerv]]

Surely what JS desperately needs is a getOlsenTimezoneID() function? That, together with the UTC time which is already available, should allow a JS app with access to a copy of the Olsen file to correctly calculate the current and any future or past time for the computer in question, and would solve this use case and many others.

Gerv

Comment 6

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

This seems like it would've required a ECMAScript proposal that never happened, so marking INCOMPLETE.