Provide .getDSTOffset() for the Date object

NEW
Unassigned

Status

()

Core
DOM: Device Interfaces
5 years ago
5 years ago

People

(Reporter: Gene Lian (I already quit Mozilla), Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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).
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()|.
Flags: needinfo?(dbaron)
(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?
Flags: needinfo?(dbaron)
> 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.
(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.
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
You need to log in before you can comment on or make changes to this bug.